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1 장 

시 작하기 



이 장 에서는 Git 을 처음 집 하는사 람에게 필요한 내용을 다 툰다. 버전 관리 도구에 대한 약간의 배경지 
식， Git 의 특징， Git 을 설 치하는 법 그리고 Git 을 시작 하기에 앞서 필요한 설정을 하는 방법 을설명 한다. 
이 장을 다 읽고 나면 Git 의 탄생 배경과 Git 이 사 용되는 이유를 이해 하고, Git 을 시 작하기 위한 준비가 
되어 있을것 이다. 



1.1 버전관 리란? 

버견 관리 란무엇 이며， 왜 이것을 알아야 할까? 버전 관리 시 스템은 파일의 변호툴 시간에 따라 기록하 
여 과거 특정 시점의 버견을 다시 불러올 수 있는 시스렘 이다. 이 책에는 소프트 웨어의 소스 코드를 버 

견 관 리하는 예만 나 오지만 실 제로는 모든 컴퓨터 파일이 버견 관리의 대상이 될 수 있다. 
이 미지나 레이 아웃을 수정할 때마다 각각의 형태를 모두 보 존하고 심은 그래픽 디자 이너나 웹 디자이 
너라면 버견 관리 시스템 (Version Control System; VCS) 을 사 용하는 것이 현명할 수 있다. VCS 를 
사 용하면 개별 파일 흑은 프 로젝트 전체를 이견 상태로 되돌 리거나 시간에 따른 변경 사항을 검토할 수 
있 으며, 문제가 되는 부분을 누 가마지 막으로 수정했 는지， 누가 언제 이슈를 만들어 냈는지 등을 알수있 
다. 또한 파일을 잃어버 리거나 무언가 잘못 되어도 대개 쉽게 복구할 수 있다. 그리고 이 모든 장점을 누 
리는 데는큰 노력이 들지않 는다. 



1.1.1 로걸버 전관리 시스템 

대 부분의 사 람들이 버견 관리를 위해 쓰는 방법은 파일을 다른 디텍 토리에 복 사하는 것이다 (똑 똑한사 
람 이라면 디 텍토리 이름에 시간을 넣을 것이다 ). 이 방법은 간 단하고 자주사 용되는 방법 이지만 실수가 
발 생하기 쉽다. 어느 디텍토 리에서 작 업하고 있 었는지 잊어 버리고 영뚱한 파일을 덮어 쓰거나 의 도하지 
않았 던위치 로복사 할수도 있다. 

이 문제를 해 결하기 위해 오 래견에 프 로그래 머들은 간단한 데 이터베 이스에 파일의 변경 사항을 기록하 
는로걸 버견 관리 시 스템을 만 들었다 (그림 1—1 참조 ). 

유 명했던 VCS 도구 들중현 재에도 널리 쓰이는 것으로 RCS 라불 리는시 스템이 있다. 그 예로 Mac OS 
X 운 영체제 에서는 개발 도구를 설 치하면 RCS 가 딸려 온다. RCS 의 기 본적인 동작 방식은 각 리 비견들 
간의 패치 세트 (patch set) 라 고하는 데 이터의 차이 점들을 특별한 형식의 파일에 저장， 특정 시점의 파 
일 내용을 보고 싶을 때 해당 시점 까지의 패 치들을 모두 더하여 파일을 만들 어내는 것 이다. 
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그림 1 .1 ： 로 걸버전 관리 다이 어그램 



1.1.2 중앙집 중식버 전관리 시스템 



또 다른 문제는 시스템 외부에 있는 개발 자들과 함께 작 업하는 것 이다. 중앙 집중식 버견 관리 시 
스템 (Centralized Version Control System; CVCS) 은 이 문제를 해 결하기 위해 개발 됐다. CVS, 
Subversion, Perforce 와 같은 시스 템들이 여기에 속 한다. CVCS 에서는 버전 관 리되는 모든 파일을 
저 장하는 하나의 서버 오ᅡ, 이 중앙서 버에서 파일 들을가 겨오는 (checkout) 다수의 클라 이언트 가존개 
한다. 오 랫동안 사용된 이 방식 은지금 까지도 버견 관리의 대 표적인 방 식이다 (그림 1 -2 참조 ). 



Computer A 

Checkout 
file 
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Checkout 
file 




Central VCS Server 



Version Database 



version 3 



version 2 



version 1 



그림 1 .2: 중앙 집중식 버전 관리 다이 어그램 



CVCS 는 로컬 VCS 에 비해 장점이 많다. 누구나 다른 사 람들이 무엇을 하고 있는지 알 수 있고, 관리자 
는 누가 무엇을 할 수 있는지 꼼 꼼하게 관리할 수 있다. CVCS 를 관 리하는 것은 수많은 클라이 언트의 로 

컬 데이 터베이 스를관 리하는 것보다 «썬 쉽다. 

그러나 CVCS 는 심각한 단점이 있다. 증앙서 버가잘 못되면 모 든것이 잘못된 다는점 이다. 서버 가다운 
될경우 서버가 다시 복구될 때까지 다른 사 람과의 협 업도， 진행 중 0 1 던 작업을 버전 관 리하는 것도 불가 

능해 진다. 중앙 데 이터베 이스가 저장된 하드디 스크에 오류가 발 생하고 백업도 없 다면， 사 람들이 각자 

자신의 컴 퓨터에 가지고 있던 스냅샷 외에 는그동 안쌓인 프로 젝트의 이력 을모두 잃게 된다. 로컬 VCS 

시 스템도 같은 문제가 있다. 프로 젝트의 모든 이력이 한 곳에만 있 을경우 이것은 피할 수 없는 문 제다. 
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1.2 절 짧 게보는 Git 의역사 
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그림 1 .3: 분산 버전 관리 시스템 다이 어그램 

게다가 대 부분의 DVCS 에서는 다수의 원격 저장소 (remote repository) 를 갖는 것이 가 능하기 때문 
에 동시에 여러 그룹 과여러 방법으 로함께 작 업할수 있다. 이로 인해 게 층모델 (hierarchical model) 
등 중 앙집중 시스템 에서는 할 수 없는 다양한 작업 방식 (workflow) 들을 사 용해볼 수 있다. 

1.2 짧 게보는 Git 의역사 

인생을 살다 보면 여러 가지 일들이 벌어 지듯이 Git 의 삶 또한 창 조적인 파괴와 모순 속에서 시 작되었 
다. 리눅스 커널은 굉장히 규모 가큰오 픈소스 프로젝 트다. 리눅스 커널의 일 생에서 대부 분시절 은패치 
와 단순 압축 파 일로만 관리 했다. 2002 년에 드디어 리눅스 커널은 BitKeeper 라고 불리는 상용 DVCS 
를 사용하 기시작 했다. 

2005 년에 커뮤 니티가 만드는 리눅스 커널과 이익을 추 구하는 회사가 개발한 BitKeeper 의 관게는 를 
어 겼다. BitKeeper 의 무료 사용이 제고된 것 이다. 이 사건은 리눅스 개발 커 뮤니티 (특히 리눅스 창시 
자 리누스 토 발즈) 가 자체 도구를 만드는 계기가 됐다. Git 은 BitKeeper 를 사용 하면서 배운 교훈을 기 
초로 아래와 같은목 표를세 웠다: 

• 빠 른속도 

• 단순 한구조 

• 비선 형격인 개발 (수천 개의 동시 다 발격인 브 랜치) 

• 완벽 한분산 
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1.1.3 분산버 전관리 시스템 

분산 버견 관리 시스렘 (Distributed Version Control System; DVCS) 은 앞서 말한 문제를 해결하 
기 우ᅵ해 개발되 었다. Git, Mecurial, Bazaar, Dares 등 DVCS 에 서는클 라이언 트가파 일들의 마지막 
스 냅샷을 가 져오는 대신 저장소 (repository) 를 통째로 복제 한다. 따라서 서버에 문제가 생겨도 어느 
클라이 언트든 복제된 저 장소를 다시 서버로 복 사하면 서버가 복구 된다. 체 크아웃 (checkout) 을할 때 
마 다견체 백업이 일 어나는 셈이다 (그림 1—3 참조 ). 
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- 리눅스 커널 같은 대형 프로젝 트에도 유 용할것 (속 도나 데이터 크기 면 에서) 

Git 은 2005 년 탄 생하고 나서 아직도 초기 목표를 그대로 유 지하고 있다. 그러 면서도 사 용하기 쉽게 진 
화하고 성숙 했다. Git 은 미친 듯이 빨라서 대형 프로 젝트에 사용 하기도 좋다. Git 은 동시다 발적인 브랜 
치에도 고떡없 는슈퍼 울트라 브랜침 시스 템이다 (3 장참고 ). 



1.3 Git 기초 

Git 의 핵심은 뭘까? 이 질문은 Git 을 이해 하는데 굉장히 중요 하다. Git 이 무 엇이고 어떻게 동작 하는지 
이해 한다면 쉽게 Git 을 효과적 으로사 용할수 있다. Git 을배 우려면 Subversion 이나 Perforce 같은 
다른 VCS 를사 용하던 경험 을지워 버려야 한다. Git 은 미 요하게 달라서 다른 VCS 에서 쓰던 개 념으로 
는 헷갈릴 거다. 사용자 인터페 이스는 매우 비숫하 지만, 정보를 취 급하는 방식이 다 르다. 이런 차이점 
을 이 해하면 Git 을사 용하는 것이 어렵지 않다. 



1.3.1 델타가 아니라 스냅샷 

Subversion 과 Subversion 비숫한 놈들과 Git 의 가장 큰 차 이점은 데 이터를 다루는 방법에 있다. 
큰 를에서 봤을 때 대 부분의 VCS 시 스템이 관 리하는 정보는 파 일들의 목록 이다. CVS, Subversion, 
Perforce, Bazaar 등의 시 스템은 파일의 집 합으로 정보를 관리 한다. 각 파일의 변화를 그림 1 -4 처럼 
시 간순으 로관리 한다. 



■ Checkins over lime - 



( Version 1 ) ( Version 2 ) ( Version 3 ^ ( Version 4 ^ ( Version 5 ) 

( file A ) —— Al ) A2 ) 

( file B ) Al ) »■ ( A2 ) 

( file C ^ —— Al ) A2 J A3 ) 

그림 1.4: 각 파일에 대 한변화 (델타 ) 를저장 하는시 스템들 



Git 은 이런 식으로 데 이터를 저장 하지도 취급 하지도 않 는다. 대신 Git 의 데 이터는 파일 시 스템의 스냅 
샷이라 할 수 있으며 크기가 아주 작다. Git 은 커밋 하거나 프로 젝트의 상태를 저장할 때마다 파일이 존 
재하 는그순 간을중 요하게 여 긴다. 파일이 달 라지지 않 았으면 Git 은 성능을 위해서 파 일을저 장하지 않 
는다. 단지 이견 상태의 파일에 대한 링크만 저장 한다. Git 은 그림 1 -5 처럼 동작 한다. 



- Checkins over time - 



( Version 1 ) ( Version 2 ^ ( Version 3 ^ ( Version 4 ) ( Version S ) 



V A 7 C A1 J A1 ' ( A2 J { A2 

Q ^ Q & 

Q UD Q C:« j & 

그림 1 .5: Git 은 시간 순으로 프로 젝트의 스 냅샷을 저 장한다 



이것이 Git 이 다른 VCS 와구분 되는점 이다. 이점 때문에 Git 는 다 른시스 템들이 과거 로부터 답 습해왔 
던버전 컨 트를의 개념과 다 르다는 것이고 많은 부분을 새로운 관 점에서 바라 본다. Git 은 강력한 도구 
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1.3 절 Git 기초 



를지원 하는작 은파일 시스템 이다. Git 은 단순한 VCS 가아 니다. 이제 3 장에서 설명할 Git 브탠 치를사 
용하면 얻게 되는 이득이 무 엇인지 설명 한다. 

1.3.2 거 의모든 명령을 로걸에 서실행 

거의 모든 명렁이 로컬 파일과 데이 터만사 용하기 때문에 네트 워크에 있는 다른 컴퓨터 는필요 없다. 대 
부분의 명 령어가 네트 워크의 속도에 영향을 받는 CVCS 에 익숙 하다면 Git 이 매우 놀라울 것 이다. Git 
의 이런 특 징에서 나오는 미칠듯 한속도 는오직 Git 느 님만이 구 사할수 있는초 인격인 능력 이다. 프로 
젝트의 모든히 스토리 가로컬 디 스크에 있기 때문에 모든 명 렁을순 식간에 실행 된다. 
예 를들어 Git 은프로 젝트의 히스 토리를 조회할 때 서버 없이 조회 한다. 그 낭로컬 데이 터베이 스에서 
히스 토리를 읽어서 보여 준다. 그래서 눈 깜짝할 사이에 히스 토리를 조회할 수 있다. 어떤 파일의 현재 
버전과 한 달 견의 상태를 비교 해보고 싶을 때도 Git 은 그낭 한 달 전의 파일과 지금의 파일을 로 컬에서 
찾 는다. 파일을 비 교하기 위해 리 모트에 있는 서버에 접 근하고 나서 예전 버전을 가겨올 필요가 없다. 
즉오 프라인 상태 에서도 비교할 수 있다. 비행기 나기차 등에서 작 업하고 네트 워크에 집 속하고 있지 않 
아도 커밋할 수 있다. 다른 VCS 시스템 에서는 불 가능한 일 이다. Perforce 는 서버에 연결할 수 없을 때 
할수있 는일이 별로 없다. Subversion 이나 CVS 에서도 마찬가 지다. 데 이터베 이스에 집근할 수없어 
서 파일을 편집할 수는 있 지만， 커밋할 수 없다. 매우 사소해 보 이지만 실제로 이 상황에 부닥 처보면 느 
껴지 는차이 가매우 크다. 

1.3.3 Git 의 무결성 

Git 은 모든 데 이터를 저 장하기 전에 체크심 (또는 해시) 을 구하고 그 체크 심으로 데 이터를 관리 한다. 
체크심 없이 어 떠한파 일이나 디텍토 리도변 경할수 없다. 체 크심은 Git 에서사 용하는 가장기 본적인 
(Atomic) 데이터 단 위이자 Git 의 기본 철학 이다. Git 없 이는체 크섬을 다룰 수 없어서 파일의 상태도 
알 수없고 심지어 데 이터를 잃 어버릴 수도 없다. 

Git 은 SHA—1 해시를 사용하 여체크 섬을만 든다. 만든체 크섬은 40 자 길이의 16 진수 문자열 이다. 파 
일의 내 용이나 디 롁토리 구조를 이 용하여 체크 심을구 한다. SHA—1 은아 래처럼 생 겼다: 



24b9da6552252987aa493b52f8696cd6d3b00373 



Git 은모든 것을해 시로식 별하기 때문에 이런 값 은여기 겨기서 보 인다. 실제로 Git 은파 일을이 름으로 
겨 장하지 않고 해당 파일의 해시로 저장 한다. 

1.3.4 Git 은데이 터를추 가할뿐 

Git 으로무 얼하든 데이터 를추가 한다. 도 ᅵ돌리 거나데 이터를 삭제할 방법이 없다. 다른 VCS 처럼 Git 

도 커 밋하지 않으면 변경 사항을 잃어 버릴수 있다. 하 지만, 일단 스 냅샷을 커 밋하고 나면 데 이터를 잃어 
버 리기어 렵다. 

Git 을 사 용하면 프로 젝트가 심 각하게 망가질 걱정 없이 매우 즐겁게 여러 가지 실험을 해볼수 있다. 9 
장을 보면 Git 이 데 이터를 어떻게 저 장하고 손실을 어떻게 복 구해야 할지 알 수 있다. 

1.3.5 세가 지상태 

이 부분 은증요 하기에 집 중해서 읽어야 한다. Git 을공 부하기 위해 반드시 겊고 님 어가야 할부분 이다. 
Git 은 파일을 Committed, Modified, Staged 이렇게 세 가지 상태 로관리 한다. Committed 란데이 
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터 가로컬 데 이터베 이스에 안 전하게 저장됐 다는것 을의미 한다. Modified 는수정 한파일 을아직 로컬 
데 이터베 이스에 커 밋하지 않은 것을말 한다. Staged 란현재 수 정한파 일을곧 커밋할 것이라 고표시 
한상태 를의미 한다. 

이 세 가지 상태는 Git 프로 젝트의 세 가지 단계와 연결돼 있다. Git 디텍 토리, 워킹 디텍 토리， Staging 
Area 이렇게 세 가지 단게를 이 해하고 넘어 가자. 



Local Operations 
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directory 



staging 
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c 



git directory 
(repository) 



checkout 



the project 



commit 



그림 1 .6： 워킹 디렉 토리， Staging Area, Git 디 텍토리 



Git 디렉 토리는 Git 이 프로 젝트의 메타 데이터 와객체 데이 터베이 스를겨 장하는 곳을말 한다. Git 디랙 

토리가 Git 의 핵심 이다. 다른 컴 퓨터에 있는 저 장소를 Clone 할 때 Git 디텍 토리가 만들어 진다. 

워킹 디 랙토리 는프로 젝트의 특정 버전을 Checkout 한것 이다. Git 디랙 토리는 지금작 업하는 디스크 

에 있고 그 디롁 토리에 압축된 데이 터베이 스에서 파일을 가 겨와서 워킹 디랙 토리를 만 든다. 

Staging Area 는 Git 디롁 토리에 있다. 단순한 파 일이고 곧 커밋할 파일에 대한 정보를 저장 한다. 종 

종인 덱스라 고불리 기도하 지만, staging Area 라는 명칭이 표준이 되 어가고 있다. 

Git 으로 하는 일 은기본 격으로 아래와 같다: 

- 워킹 디렉토 리에서 파일을 수정 한다. 

• Staging Area 에 파일을 Stage 해서 커밋할 스 냅샷을 만 든다. 

• Staging Area 에 있는 파 일들을 커 밋해서 Git 디텍 토리에 영 구적인 스냅 샷으로 저장 한다. 



Git 디렉 토리에 있는 파 일들은 Committed 상태 이다. 파일을 수 정하고 Staging Area 에 추 가했다 
면 Staged 이다. 그리고 Checkout 하고 나서 수정했 지만， 아직 Staging Area 에 추 가하지 않 았으면 
Modified 이다. 2 장에서 이 상태에 대해 좀 더 자세히 배 운다. 특히 Staging Area 를 어떻게 이 용하는 
지 혹은 아예 생 락하는 방법도 설명 한다. 



1.4 Git 설치 

Git 을 사용 하려면 우선 설 치해야 한다. 다양한 방 법으로 Git 을 설치할 수 있지만 두 가지 방법이 가장 
일반격 이다. 하나는 소스 코드로 컴파 일하여 설 치하는 방 법이고 다른 하나는 각 운 영체제 (흑은 플 랫폼) 

의 패키 지를사 용하여 설 치하는 방법 이다. 
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1.4 절 Git 설치 



1.4.1 소스코 드로설 치하기 

소스 코드로 설 치하면 Git 의 가장 최신 버전을 설치할 수 있기 때문에 컴파 일하여 설치할 시간이 있으 
면 소스 코드로 Git 을 설 치하는 것이 좋다. Git 은 계속 UI 를 개 선하고 있기 때문에 최신 버견을 사용하 
면좋 은기능 을빨리 사 용할수 있다. 리눅 스패키 지는보 통최신 버견이 아니 고예전 버견 이다. 그래서 
Backport 를 사용 하거나 소스 코드로 설 치하는 것도 좋은 대안 이다. 

Git 을 설치 하려면 아래와 같은 라 이브러 리들이 필요 하다. Git 은 curl, zlib, openssl, expat, libiconv 
를 필요로 한다. 예 를들어 Fedora 처럼 yum 을 사용하 는시스 템이나 apt-get 이 있는 데비안 류시스 
템이면 아래 명령 어를실 행하여 의 존패키 지를설 치할수 있다: 



$ yum install curl— devel expat— devel gettext-devel \ 
openssl— devel zlib— devel 

$ apt— get install libcurl4-gnutls-dev libexpat1-dev gettext \ 
libz-dev libssl-dev 



필요한 라이브 러리를 모두 설 치하고 다음 단계를 진행 한다. Git 웹 사이 트에서 최신 스 냅샷을 가져온 

다: 



http://git-scm.com/download 



그 리고컴 파일하 고설치 한다: 

$ tar -zxf git-1 .7.2.2.tar.gz 

$ cd git-1 .7.2.2 

$ make pref ix=/usr/local all 

$ sudo make pref ix=/usr/local install 




설치한 다음 부터는 Git 을 사 용하여 Git 소스 코드를 수정할 수 있다: 



$ git clone git://git. kernel. t^rg/p 니 b/scm/git/git. git 



1.4.2 리눅스 에설치 

리눅 스에서 패 키지로 Git 을 설치할 때에는 보통 각 배포 판에서 사 용하는 패키지 관리 도구를 사 용하여 
설치 한다. Fedora 에서 는아래 와같이 한다: 

$ yum install git-core 
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Ubuntu 같은 데 비안류 배포판 에서는 apt-get 을 사용 한다: 

$ apt-get install git 

1.4.3 Mac 에설 치하기 

Mac 에 Git 을 쉽게 설 치하는 방법은 두 가지가 있다. GUI 인스 톨러가 가장 쉽게 사용할 수 있다. 
SourceForge 페이 지에서 내려받 는다: 

http: //so 니 reef orge.net/proj ects/git—osx ᅳ installer/ 




$ sudo port install git-core +svn +doc +bash— completion +gitweb 

이제 설치는 했다. 만약 Subversion 저 장소를 Git 과 함께 사 용해야 하면 svn 도 필요 하다. 
1.4.4 윈도 에설치 

윈도 에서도 Git 을 쉽게 설치할 수 있다. 그저 구글 코드 페이 지에서 msysGit 인스 를러를 내 려받고 실 
행하면 된다: 

http://msysgit . github . com/ 
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1.5 절 Git 최 초설정 



설치가 완 료되면 a」 프로 그램과 GUI 프로 그램을 들 다 사용할 수 있다. (：니 프로그 램에는 SSH 클라 
이 언트가 포함돼 있기 때문에 유용 하다. 

Windows 사용자 필독: 이 책에서 소 개하는 다 양한명 렁어를 사용하 려면유 닉스스 타일의 msysGit 
쉘을 사용하 는것이 좋다. 어껄 수없이 Windows 에 포함된 기본쉘 (Command Prompt, 명령 프롬 
프트) 을 꼭써야 하면 공백이 포함된 파라 미터를 Git 명 령어에 님길 때 작은 따옴표 (") 대신 큰 따옴 
표 (" ") 를사 용해야 한다. 파 라미터 끝에 8 기호가 있을 때도 큰 따 옴표로 파라 미터를 감싸야 한다. 
Windows 쉘에서 8 기호는 다음 줄로 명 령어가 이 어김을 나타 낸다. 



1.5 Git 최 초설정 

Git 을 설 치하고 나면 Git 의 사용 환경을 적 질하게 설정해 주어야 한다. 한 번만 설 정하면 된다. 설정한 
내용은 Git 을 업그레 이드해 도유지 된다. 언 제든지 다시 바꿀수 있는명 렁어가 있다. 
'git config' 라는 도구로 설정 내용을 확 인하고 변경할 수 있다. Git 은 이 설정에 따라 동작 한다. 이때 
사 용하는 설정 파일은 세 가지나 된다. 

• /etc/gitconfig 파일: 시 스템의 모든사 용자와 모든저 장소에 격용되 는설정 이다. git config -- 
system 옵 션으로 이 파일을 읽고 쓸 수 있다. 

• -/.gitconfig 파일: 특정 사용자 에게만 격용되 는설정 이다. git config -global 옵션으 로이파 
일을읽 고쏠수 있다. 

• .git/config: 이 파일은 Git 디롁 토리에 있 고특정 겨장소 (혹 은현재 작업 중인 프로 젝트) 에만격 
용 된다. 각설 정은역 순으로 우선시 된다. 그래서 .git/config 가 /etc/gitconfig 보 다우선 한다. 

윈도용 (께은^0얘 디텍토 리(%배£8?(«ᄄ마£% 환경 변수) 에 있는 .gitconfig 파 일을찾 는다. 보통 C: 
\Documents and Settings\$USER 또는 C:\Users\$USER 이다 (윈 도우 에서는 $USER 대신 %USERNAWIE% 를사용 

한다 ). 그리고 msysGit 도 /etc/gitconfig 를 가지고 있다. 경로는 MSys 루트에 따른 상대 경 로다. 인 
스 를러로 msysGit 을 설치할 때 설치 경로를 선택할 수 있다. 

1.5.1 사용 자정보 

Git 을 설 치하고 나서 가장 먼겨 해야 하는 것은 사용자 이름과 이메일 주소를 설 정하는 것 이다. Git 은 
커 밋할때 마다이 정보 를사용 한다. 한번커 밋한후 에는정 보를변 경할수 없다: 

$ git config —global user. name "John Doe" 



$ git config —global user. email j ohndoe@example . com 




다시 말 하자면 -global 옵 선으로 설정한 것은 딱 한 번만 하면 된다. 해당 시스 템에서 해당 사 용자가 
사용할 때 에는이 정보를 사용 한다. 만약 프로젝 트마다 다른 이름과 이메일 주소를 사 용하고 싶으면 ᅳ 

global 옵션을 빼고 명령을 실행 한다. 

1.5.2 편집기 

사용자 정보를 설 정하고 나면 Git 에서 사용할 텍스트 편 집기를 고 른다. 기본 적으로 Git 은 시 스템의 기 
본편 집기를 사용하 고보통 Vi 나 Vim 이다. 하 지만， Emacs 같 은다른 텍스트 편 집기를 사용할 수있고 
아래와 같이실 행하면 된다: 
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$ git config —global core. editor emacs 



1.5.3 Diff 도구 

Merge 충돌을 해 결하기 위해 사 용하는 Diff 도구를 설정할 수 있다. vimdiff 를 사 용하고 싶으면 아래 
와같 이실행 한다: 

$ git config —global merge. tool vimdiff 

이렇게 kdiff3， tkdiff, meld, xxdif, emerge, vimdiff, gvimdiff, ecmerge, opendiff 를사 용할수 
있다. 물론 다른 도구도 사용할 수 있다. 자세한 내용은 7 장에서 다 툰다ᅳ 

1.5.4 설 정확인 

git config —list 명 렁을실 행하면 설정한 모든것 을보여 준다: 

$ git config —list 
user.name=Scott Chacon 
user.email=schacon@gmail . com 
color. status=auto 
color. branch=auto 
color. interactive=auto 
color. diff=auto 



Git 은 같은키 를여러 파일 (/etc/gitconfig 와〜 /.gitconfig 같은) 에서 읽기 때문에 같 은키가 여러개 있 
을 수도 있다. 이러면 Git 은 나중 값을 사용 한다. 

git config {key} 명 령으로 Git 이 특정 Key 에 대해 어떤 값 을사용 하는지 확 인할수 있다: 



$ git config user. name 
Scott Chacon 




1.6 도움 말보기 

명 렁어에 대한도 움말이 필요할 때 도움말 을보는 방 법은세 가 지다: 
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1.7 절 요약 



$ git help <verb> 
$ git <verb> —help 
$ man git-<verb> 




예를 들어 아래와 같이 실 행하면 config 명렁에 대한 도 움말을 볼 수 있다: 



$ git help config 



도 움말은 언제 어 디서나 볼 수 있다. 오 프라인 으로도 볼 수 있다. 도 움말과 이 책으로 부 족하면 다른 

사람의 도움을 받는 것이 필요 하다. Freenode IRC 서버 (irc.freenode.net) 에 있는 #git 이나 #github 
채널로 찾아 가라. 이 채 널에는 보통 수백 명의 사람이 접속해 있다. 이 사 람들은 모두 Git 에 대해 잘 알 
고 있다. 기 끼이도 오월것 이다. 



1.7 요약 

우리는 Git 이 무 엇이고 지 금까지 사용해 온 다른 CVCS 와 어떻게 다른지 배 웠다. 시 스템에 Git 을 설치 
하고 사용자 정보도 설정 했다. 다음 장 에서는 Git 의 사 용법을 배 운다. 
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Git 을 사 용하는 방법을 알고 싶은데 한 챕 터밖에 읽을 시간이 없다면 2 장을 읽어야 한다. Git 에서 자주 
사 용하는 명 렁어는 모두 2 장에 등장 한다. 2 장을 다 읽으면 저 장소를 만들고 설 정하는 방법, 파일을 추격 
하거나 (Track) 추적을 그 만두는 방법, 변경 내용을 Stage 하고 커 밋하는 방법을 알게 된다. 그리고 또 
파일이 나파일 패턴을 무시 하도록 Git 을 설 정하는 방법, 실수를 쉽고 빠르게 만 회하는 방법， 프 로젝트 
히스 토리를 조 회하고 커밋을 비 교하는 방법, 리모트 저 장소에 Push 하고 Pull 하는 방법을 살펴 본다. 



2.1 Git 저장소 만들기 

Git 저 장소를 만드는 방법은 두 가 지다. 기존 프로 젝트를 Git 저 장소로 만드는 방법이 있고 다른 서버 
에 있는 저 장소를 Clone 하는 방법이 있다. 

2.1.1 기존 디텍 토리를 Git 저 장소로 만들기 

기존 프로 젝트를 Git 으로 관 리하고 싶을 때, 프로 젝트의 디텍 토리로 이 동해서 아래과 같은 명령을 실 
행 한다. 



$ git init 



이 명렁은 .git 이라는 하위 디텍 토리를 만 든다. .git 디텍토 리에는 저 장소에 필요한 뼈대 파일 
(Skeleton) 이 들어 있다 (.git 디텍 토리가 막 만 들어진 직후에 어떤 파일이 있 는지에 대한 내용은 9 
장에서 다툰다 ). 이 명령 만으로 는아직 프로 젝트의 어떤 파 일도관 리하지 않 는다. 

Git 이 파일을 관 리하게 하려면 저 장소에 파일을 추 가하고 커 밋해야 한다. git add 명 령으로 파일을 추 
가하 고커밋 한다: 

$ git add *.c 
$ git add README 

$ git commit -m ' initial project version ' 



매우 짧은 시간에 명 령어를 몇개 실 행해서 Git 저 장소를 만들고 파일이 관 리되게 했다. 
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2.1.2 기존저 장소를 Clone 하기 

다른 프로 젝트에 참여 하거나 (Contribute) Git 저 장소를 복 사하고 싶을 때 git clone 명렁을 사용한 
다. 이미 Subversion 같은 VCS 에 익숙한 사용자 에게는 checkout 이 아니라 clone 이라 는점이 도드라 
져 보일 것 이다. Git 이 Subversion 과 다른 가장 큰 차 이점은 서버에 있는 모든 데 이터를 복사 한다는 

것 이다. git clone 을실행 하면프 로젝트 히스토 리를견 부받아 온다. 실제로 서버의 디스 크가망 가겨도 
클라 이언트 저장소 중에서 아무 거나하 나가겨 다가복 구하면 된다 (서버 에만격 용했던 설 정은복 구하지 
못하지 만모든 데이 터는복 구된다 - 4 장에서 좀 더 자세히 다툰다 ). 

git clone [uri] 명렁 으로저 장소를 Clone 한다. Ruby 용 Git 라이브 러리인 Grit 을 Clone 하려 면아래 
과같 이실행 한다: 



$ git clone git://github.com/schacon/grit .git 



이 명렁은 "grit" 이라 는디롁 토리를 만들고 그안에 .git 디텍토 리를만 든다. 그 리고저 장소의 데 이터를 
모두 가 겨와서 자 동으로 가장 최신 버전을 Checkout 해 놓 는다. grit 디텍 토리로 이 동하면 Checkout 
으로 생성한 파일을 볼 수있고 당장 하고차 하는 일을 시작할 수 있다. 아래과 같은 명령을 사 용하여 저 
장소를 Clone 하면 "grit" 이 아니라 다른 디 텍토리 이 름으로 Clone 할 수 있다: 



$ git clone git://github.com/schacon/grit .git mygrit 



디 텍토리 이름이 mygrit 이 라는것 만빼면 이 명렁의 결과 와앞선 명령의 결과는 같다. 

Git 은 다양한 프로 토콜을 지원 한다. 이제 까지는 git ： // 프로 토콜을 사 용했지 만 http( s ) ： // 를 사용할 
수도 있고 user®sen/er:/path.git 처럼 SSH 프 로토콜 을사용 할수도 있다. 자세한 내용은 4 장에서 다툰 
다. 4 장 에서는 각 프로 토콜의 장 단점과 Git 저 장소에 집 근하는 방법을 설명 한다. 

2.2 수정하 고저장 소에저 장하기 

만질 수 있는 Git 저 장소를 하나 만 들었고 워킹 디롁 토리에 Checkout 도 했다. 이제는 파일을 수정하 
고 파일의 스 냅샷을 커밋해 보자. 파일을 수정하 다가겨 장하고 싶으면 스 냅샷을 커밋 한다. 
워킹 디텍 토리의 모 든파일 은크게 Tracked (관 리대 상임) 와 Untracked (관 리대 상이 아님) 로 나 눈다. 
Tracked 파일은 이미 스 냅샷에 포함돼 있던 파일 이다. Tracked 파일은 또 Unmodified (수 정하지 않 
음) 와 Modified (수 정함) 그리고 Staged (커 밋하면 겨 장소에 기록 되는) 상태중 하나이 다. 그리고 나 
머지 파일 은모두 Untracked 파일 이다. Untracked 파일 은워킹 디텍 토리에 있 는모든 파일이 스냅샷 
에 포함돼 있는 것은 아니고 Staging Area 에 있는 것도 아 니다. 처음 저 장소를 Clone 하면 모든 파일 
은 Tracked 이면서 Unmodified 상태가 된다. 파일을 Checkout 하고 나서 아무 것도수 정하지 않았기 
때문에 그 렇다. 

마지막 커 밋이후 아직 아 무것도 수 정하지 않은 상 태에서 어떤 파일이 수 정되면 Git 은 그 즉시 파일을 
Modified 상태로 인식 한다. 그리고 이 수정한 파일을 Stage 하고 Staged 상태인 파일을 커밋 한다. 이 
라이프 사이클 을그림 2-1 처럼 계 속반복 한다. 

2.2.1 파일의 상태확 인하기 

파일의 상태 를확인 하려면 보통 git status 명령 을사용 한다. Clone 한후에 바로이 명 령을실 행하면 
아래 과같은 메시지 를볼수 있다: 
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File Status Lifecycle 




그림 2.1: 파일의 라이 프사아 



$ git status 
On branch master 

nothing to commit, working directory clean 

위의 내용은 파일을 하나도 수 정하지 않 았다는 것을 말해 준다. Tracked 나 Modified 상태인 파일이 
없다는 의 미다. Untracked 파일은 아직 없어서 목록에 나 타나지 않 는다. 그리고 현재 작업 중인 브랜 
치를 알려 준다. 기본 브 랜치가 master 이기 때문에 현재 master 로 나오는 것 이다. 브랜치 관련 내용은 

m\ 알아 가자. 다음 장에서 브 탠치와 레퍼 런스에 대해 자세히 다 툰다. 

프로 젝트에 README 파일을 만들어 보자. README 파일은 새로 만든 파 일이기 때문에 git status 를 실행하 

면 'Untracked files' 에 들어 있다: 

$ vim README 
$ git status 
On branch master 
Untracked files: 
(use "git add <file>. . . " to include in what will be committed) 

README 

nothing added to commit but untracked files present (use "git add" to track) 

README 파일은 Untracked files 부분에 속해 있는데 이것은 README 파일이 Untracked 상 태라는 것 

을말 한다. Git 은 Untracked 파일 을아직 스냅샷 (커밋 ) 에 넣 어지지 않 은파일 이라고 본다. 파일이 
Tracked 상태가 되기 견 까지는 Git 은 질대 그 파일을 커 밋하지 않 는다. 그래서 일 하면서 생 성하는 바 
이너리 파일 같은 것을 커 밋하는 실수는 하지 않게 된다. README 파일을 추 가해서 직접 Tracked 상 
태로 만들어 보자. 

2.2.2 파일을 새로추 적하기 

git add 명 렁으로 파일을 새로 추적할 수 있다. 아래 명렁을 실 행하면 Git 은 README 파일을 추적 한다: 
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I git add README 



git status 명령 을다시 실 행하면 README 파일이 Tracked 상태 이면서 Staged 상태 라는것 을확인 
할수 있다: 

$ git status 
On branch master 
Changes to be committed: 
(use "git reset HEAD <f ile>. . . " to unstage) 

new file: README 



'Changes to be committed' 에 들어 있는 파일은 Staged 상 태라는 것을 의미 한다. 커 밋하면 git 

add 를 실행한 시점의 파일이 커 밋되어 저장 소히스 토리에 남 는다. 앞에서 git init 명령을 실행했 을때， 
그다음 git add (files) 명령을 실행했 던걸기 억할것 이다. 이것 은작업 디렉토 리에있 는파일 들을추 
격하기 시 작하게 하 였다. git add 명렁은 파일 또는 디렉 토리의 경 로명을 아규 먼트로 받 는다; 만일 디 
롁 토리를 아규먼 트로줄 경우, 그디 텍토리 아래에 있는모 든파일 들을재 귀격으 로추가 한다. 

2.2.3 Modified 상태의 파일을 Stage 하기 

이미 Tracked 상태인 파일을 수 정하는 법을 알아 보자. benchmarks. rb 라는 파일을 수 정하고 나서 git 
status 명렁을 다시 실 행하면 결과는 아래와 같다: 

$ git status 
On branch master 
Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

new file: README 

Changes not staged for commit: 
(use "git add <file>. . . " to update what will be committed) 
(use "git checkout ― <file>. . . " to discard changes in working directory) 

modified ： benchmarks . rb 



이 benchmarks. rb 파일은 Changes not staged for commit 에 있다ᅳ 이것은 수정한 파일이 Tracked 상태 

이지만 아직 Staged 상태는 아 니라는 것 이다. Staged 상태로 만 들려면 git add 명렁을 실 행해야 한 
다. git add 는 파일을 새로 추격할 때도 사 용하고 수정한 파일을 Staged 상태로 만들 때도 사용 한다. 
git add 를 실 행하여 benchmarks.rb 파일을 Staged 상태로 만들고 git status 명 렁으로 결과를 확인 
해 보자: 
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$ git add benchmarks. rb 
$ git status 
On branch master 
Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

new file: README 
modified : benchmarks . rb 



두 파일 모두 Staged 상태 이므로 다음 커밋에 포함 된다. 하 지만, 아직 더 수 정해야 한다는 것을 알게 
되어 바로 커 밋하지 못하는 상황이 되 었다고 하자. 이 상 황에서 benchmark.rb 파일을 열고 수정 한다. 

아 마당신 은커밋 할준비 가다됐 다고생 각할테 지만, Git 은 그렇지 않다. git status 명 렁으로 파일의 

상태 를다시 확인해 보자: 

$ vim benchmarks. rb 
$ git status 
On branch master 
Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

new file: README 
modified ： benchmarks . rb 

Changes not staged for commit: 
(use "git add <file>. . . " to update what will be committed) 

modified : benchmarks . rb 



헉! benchmarks.* 가 Staged 상태 이면서 동시에 Unstaged 상태로 나 온다. 어떻게 이런 일이 가 
능 할까? git add 명 렁을실 행하면 Git 은파일 을바로 Staged 상 태로만 든다. 지 금이시 점에서 커밋을 

하면 git commit 명렁을 실 행하는 시점의 버견이 커 밋되는 것이 아니라 마지 막으로 git add 명렁을 실행 
했을때 의버견 이커밋 된다. 그 러니까 git add 명 렁을실 행한후 에또파 일을수 정하면 git add 명렁을 

다시 실 행해서 최신 버견을 Staged 상태로 만 들어야 한다: 

$ git add benchmarks. rb 
$ git status 
On branch master 
Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

new file: README 
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modified ： benchmarks . rb 



2.2.4 파일무 시하기 

어떤 파일은 Git 이 자 동으로 추가 하거나 Untracked 파일 이라고 보여줄 필요가 없다. 보통 로그 파일 

이나 빌드 시 스템이 자 동으로 생성한 파일이 그 렇다. 그런 파일을 무시 하려면 .gitignore 파일을 만들 
고 그안에 무시할 파일패 턴을격 는다. 아래는 .gitignore 파일의 예 이다: 



$ cat .gitignore 



첫번째 줄은확 장자가 .o 나 .a 인파 일을 Git 이 무시하 라는것 이고둘 째줄은 〜로 끝나는 모든파 일을무 
시 하라는 것 이다. .0 와 .a 는 각각 빌드 시 스템이 만들 어내는 오브 젝트와 아 카이브 파 일이고 ~로 끝나는 

파일은 Emacs 나 VI 같은 택스트 편 집기가 임시로 만 들어내 는파일 이다. 또 log, tmp, pid 같은 디텍토 

리 나， 자 동으로 생 성하는 문서 같은 것들도 추가할 수 있다. . gitignore 파일은 보통 처음에 만들어 두는 
것이 편리 하다. 그래서 Git 저 장소에 커 밋하고 싶지 않은 파일을 실수로 커 밋하는 일을 방지할 수 있다. 
.gitignore 파일에 입 력하는 패턴은 아래 규칙을 따 른다: 

• 아 무것도 없는 줄 이나, #로 시 작하는 줄은 무시 한다. 

- 표준 Glob 패턴 을사용 한다. 

- 디텍 토리는 술래시 (/) 를 끝에 사 용하는 것으로 표현 한다. 

- 느낌표 (！) 로시 작하는 패턴의 파 일은무 시하지 않 는다. 

Glob 패턴은 정규표 현식을 단 순하게 만든 것으로 생 각하면 되고 보통 쉘에서 많이 사용 한다. 애 스터리 
스크 (*) 는 문차가 하나도 없거 나하나 이상을 의미 하고， [abc] 는 중괄호 안에 있는 문자중 하나를 의미 
한다 (그러 니까이 경 우에는 a, b, c). 물음표 (？) 는 문자하 나를말 하고, [0-9] 처럼 중괄 호안의 캐릭터 
사이에 하이픈 (-) 을사 용하면 그 캐릭터 사이에 있 는문자 하나를 말 한다. 
다음은 .gitignore 파일의 예 이다: 



# a comment - 이 줄은 무시 한다. 

# 확 장자가 .a 인 파일 무시 
*.a 

# 윗 줄에서 확 장자가 .a 인 파일은 무 시하게 했지만 lib. a 는 무 시하지 않 는다. 
！ lib. a 

# 루트 디텍 토리에 있는 T0D0 파일은 무 시하고 subdir/TODO 처럼 하 위디텍 토리에 있는 파일은 무시하 
지 않 는다. 

/T0D0 

# build/ 디렉 토리에 있는 모든 파일은 무시 한다. 
build/ 

# 、 doc/notes. txt 、같은 파일은 무 시하고 doc/server/arch. txt 같은 파일은 무 시하지 않 는다. 
doc/*.txt 
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# 、doc、 디 렉토리 아래의 모든 .txt 파일을 무시 한다. 
doc/**/*.txt 




**/ 스 타일의 문법은 Git 1 .8.2 버 전부터 사용할 수 있다. 

2.2.5 Staged 와 Unstaged 상태의 변경 내용을 보기 

단순히 파일이 변경 됐다는 사실이 아니 라어떤 내용이 변경 됐는지 살펴 보기엔 git status 명령이 아니 

라 git diff 명령을 사 용해야 한다. 보통 우리는 '수 정했 지만, 아직 Staged 파일이 아 닌것? '과' 어떤 파 
일이 Staged 상태인 지?' 가긍 금하기 때문에 git status 명 렁으로 도충분 하다. git diff 는 Patch 처럼 
어떤 라인을 추 가했고 삭제했 는지가 긍금할 때에 사용 한다. git diff 는 나중에 더 자세히 다 툰다. 
README 파일을 수 정해서 Staged 상태로 만들고 benchmarks. rb 파일은 그낭 수정만 해 둔다. 이 
상 태에서 git status 명렁을 실 행하면 아래와 같은 메 시지를 볼 수 있다: 

$ git status 
On branch master 
Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

new file: README 

Changes not staged for commit: 
(use "git add <file>. . . " to update what will be committed) 
(use "git checkout ― <file>. . . " to discard changes in working directory) 

modified ： benchmarks . rb 



git diff 명렁을 실 행하면 수정 했지만 아직 staged 상태가 아닌 파일을 비교해 볼 수 있다: 

$ git diff 

diff —git a/benchmarks. rb b/benchmarks.rb 

index 3cb747f . .da65585 100644 

— a/benchmarks. rb 

+++ b/benchmarks.rb 

@@ —36,6 +36,10 @@ def main 

©commit. parents[0] . parents [O] . parents [0] 
end 

+ run_code(x / 'commits 1 1 ) do 

+ git. commits. size 

+ end 
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run_code(x, 'commits 2' ) do 
log = git.commits( 'master' , 15) 
log. size 



이 명렁은 워킹 디텍 토리에 있는 것과 Staging Area 에 있는 것을 비교 한다. 그래서 수 정하고 아직 
Stage 하지 않은것 을보여 준다. 

만약 커밋 하려고 Staging Area 에 넣은 파일의 변경 부분을 보고 싶으면 git diff -cached 옵션을 사 

용한다 (Git 버견 1.6.1 부터 는좀더 기 억하기 쉽게 git diff —staged 로도 사용할 수있다 ). 이 명령은 

겨 장소에 커밋한 것과 Staging Area 에 있는 것 을비교 한다: 

$ git diff ―— cached 

diff —git a/README b/README 

new file mode 1 00644 

index 0000000. . 03902a 1 

— /dev/null 

+++ b/README2 

@@ -0,0 +1,5 @@ 

+grit 

+ by Tom Preston— Werner, Chris Wanstrath 
+ http://github.com/mojombo/grit 

+Grit is a Ruby library for extracting information from a Git repository 



꼭 잊지 말 아야할 것이 있는데 git diff 명렁 은마지 막으로 커밋 한후에 수정한 것들 전 부를보 여주지 
않 는다. git diff 는 Unstaged 상태인 것들 만보여 준다. 이 부분이 조금 헷갈릴 수 있다. 수정 한파일 
을 모두 Staging Area 에 넣 었다면 git diff 명렁은 아 무것도 출 력하지 않 는다. 
benchmarks.rb 파일을 Stage 한 후에 다시 수 정해도 git diff 명렁을 사용할 수 있다. 이때는 
Staged 상태인 것과 Unstaged 상태인 것을 비교 한다: 

$ git add benchmarks.rb 

$ echo ■# test line 1 » benchmarks.rb 

$ git status 

On branch master 

Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

modified : benchmarks . rb 

Changes not staged for commit: 
(use "git add <file>. . . " to update what will be committed) 
(use "git checkout ― <file>. . . " to discard changes in working directory) 
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modified ： benchmarks . rb 



git diff 명 렁으로 Unstaged 상태인 변경 부분을 확인해 볼 수 있다: 

$ git diff 

diff —git a/benchmarks. rb b/benchmarks .rb 
index e445e28. .86b2f7c 100644 
— a/benchmarks. rb 
+++ b/benchmarks. rb 
@@ —127,3 +127,4 @@ end 
main( ) 



##pp Grit: ： GitRuby . cache_client . stats 
+# test line 




Staged 상태인 파일은 git diff —cached 옵션으 로확인 한다: 



$ git diff ―— cached 

diff —git a/benchmarks. rb b/benchmarks. rb 

index 3cb747f . ,e445e28 100644 

— a/benchmarks. rb 

+++ b/benchmarks. rb 

@@ —36,6 +36,10 @@ def main 

©commit. parents [0] .parents[0] .parents[0] 
end 

+ run_code(x / 'commits 1 1 ) do 

+ git. commits. size 

+ end 



run_code(x, 'commits 2 1 ) do 
log = git. commits ( 'master' , 15) 
log. size 




2.2.6 변경 사항커 밋하기 

수정한 것을 커 밋하기 위해 Staging Area 에 파일을 정리 했다. Unstaged 상태의 파일은 커 밋되지 않 
는다는 것을 기 억해야 한다. Git 은 생성 하거나 수 정하고 나서 git add 명 렁으로 추 가하지 않은 파일은 

커 밋하지 않 는다. 그 파일은 여견히 Modified 상태로 남아 있다. 커 밋하기 견에 git status 명 렁으로 
모든 것이 Staged 상 태인지 확인할 수 있다. 그리고 git commit 을 실 행하여 커밋 한다: 
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$ git commit 



Git 설정에 지정된 편 집기가 실행 되고, 아래와 같은 텍 스트가 자 동으로 포 함된다 (아래 예제는 Vim 
편 집기의 화면이 다). 이 편집기 는쉘의 $EDITOR 환경 변수에 등록된 편집 기이고 보통은 Vim 이나 
Emacs 을사용 한다. 또 1 장에 서설명 했듯이 git config -global core. editor 명령으 로어떤 편집기 
를사 용할지 설 정할수 있다: 

편 집기는 아래와 같은 내용을 표 시한다 (아래 예제는 Vim 편집기 ) ： 

# Please enter the commit message for your changes. Lines starting 

# with ■#■ will be ignored, and an empty message aborts the commit. 

# On branch master 

# Changes to be committed: 

# new file: README 

# modified ： benchmarks . rb 
# 



M .git/COMMIT_EDITMSG" 10L, 283C 



자 동으로 생성되 는커밋 메시지 의첫줄 은비어 있 고들째 줄부터 git status 명렁의 결과 가채워 진다. 
커밋한 내용을 쉽게 기억할 수 있도록 이 메시지 를 포함할 수도 있고 메 시지를 전부 지우고 새로 작성할 
수 있다 (수 정한 내용 을좀더 구체 격으로 남 겨들수 있다. git commit 에 -V 웁 선을추 가하면 편 집기에 
diff 메시 지도추 가된다 ). 

메 시지를 인라 인으로 첨부할 수도 있다. commit 명렁을 실행할 때 아래와 같이 -m 옵션을 사용 한다: 

$ git commit -m "Story 182： Fix benchmarks for speed" 
[master 463dc4f ] Story 182： Fix benchmarks for speed 

2 files changed, 3 insertions(+) 

create mode 1 00644 README 



commit 명 렁은몇 가지 정보를 출력 하는데 위 예제는 master 브 랜치에 커 밋했고 체 크섬은 463dc4f 이라 

고 알려 준다. 그리고 수정한 파일이 S 개이고 삭제 됐거나 추가된 줄이 S 줄인지 알려 준다. 
Git 은 Staging Area 에 속한 스 냅샷을 커밋 한다는 것을기 억해야 한다. 수정은 했 지만， 아직 Staging 
Area 에 넣지 않은 것은 다음에 커밋할 수 있다. 커밋할 때마다 프로 젝트의 스 냅샷을 기 록하기 때문에 
나중에 스냅 샷끼리 비교 하거나 예전 스냅 샷으로 되돌릴 수 있다. 

2.2.7 Staging Area 생 락하기 

Staging Area 는 커밋할 파일 을정리 한다는 점에서 매우 유용 하지만 복잡 하기만 하고 필 요하지 않은 
때도 있다. 아주 쉽게 Staging Area 를 생략할 수 있다. git commit 명령을 실행할 때 -a 옵션을 추가하 
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2.2 절 수 정하고 저 장소에 저 캉하기 



면 Git 은 Tracked 상태의 파 일을자 동으로 Staging Area 에 넣 는다. 그래서 git add 명 령을실 행하는 
수고 를덜수 있다: 

$ git status 

On branch master 

Changes not staged for commit: 
(use "git add <file>. . . " to update what will be committed) 
(use "git checkout ― <file>. . . " to discard changes in working directory) 

modified ： benchmarks . rb 

no changes added to commit (use "git add" and/or "git commit —a") 
$ git commit —a -m 1 added new benchmarks 1 
[master 83e38c7] added new benchmarks 
1 files changed, 5 insertions(+) 



이 예제에 서는커 밋하기 견에 git add 명 렁으로 benchmarks.rb 파 일을추 가하지 않았 다는점 을눈여 
겨 보자. 

2.2.8 파 일을삭 제하기 

Git 에 서파일 을제거 하려면 git rm 명 렁으로 Tracked 상태 의파일 을삭제 한후에 (정확 하게는 Staging 
Area 에서 삭 제하는 것) 커 밋해야 한다. 이 명렁 은워킹 디롁 토리에 있는파 일도삭 제하기 때문에 실제 
로지워 진다. 

만약 Git 없이 그낭파 일을삭 제하고 git status 명령 으로상 태를확 인하면 Changes not staged for 

commit (즉， Unstaged) 에 속 한다는 것을확 인할수 있다: 

$ rm grit.gemspec 

$ git status 

On branch master 

Changes not staged for commit: 
(use "git add/rm <file>. . . " to update what will be committed) 
(use "git checkout ― <file>. . . " to discard changes in working directory) 

deleted ： grit . gemspec 

no changes added to commit (use "git add" and/or "git commit —a") 



그리고 git rm 명렁을 실 행하면 삭제한 파일은 staged 상태가 된다: 

$ git rm grit.gemspec 
rm 'grit.gemspec' 
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$ git status 
On branch master 
Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

deleted ： grit . gemspec 



커 밋하면 파일은 삭 제되고 Git 은 이 파일을 더는 추 격하지 않 는다. 이미 파일을 수정 했거나 Index 에 
(역 주， Staging Area 을 Git Index 라고도 부 른다) 추가 했다면 — f 옵션을 주어 강제로 삭 제해야 한다. 
이 점은 실수로 데 이터를 삭 제하지 못 하도록 하는 안견장 치다. 한 번도 커 밋한격 없는 데 이터는 Git 으 
로복 구할수 없다. 

또 Staging Area 에서만 제 거하고 워킹 디텍 토리에 있는 파일은 지우지 않고 남겨들 수 있다. 다시 말 

해서 하드디 스크에 있는 파일은 그대로 두고 Git 만 추 적하지 않게 한다. 이것은 .gitignore 파일에 추가 
하는 것을 빼먹 었거나 대용량 로그 파 일이나 컴 파일된 파일인 .a 파일 같은 것을 실수로 추 가했을 때 쓴 
다. -cached 옵 션을사 용하여 명렁 을실행 한다: 



$ git rm ― cached readme.txt 



여러 개의 파 일이나 디롁 토리를 한 꺼번에 삭제할 수도 있다. 아래와 같이 git 01 명령에 file-glob 패 

턴 을사용 한다: 



$ git rm log/\*.log 



* 앞에 \을 사용한 것을 기억 하자. 파일명 확장 기능은 쉘에만 있는 것이 아니라 Git 자 체에도 있기 때 
문에 필요 하다. Windows 기 본쉘을 쏠때는 \ 기호를 붙이지 않 는다. 이 명령은 log/ 디텍 토리에 있는 

. log 파일을 모두 삭제 한다. 아래의 예제처 럼 할 수도 있다: 



$ git rm 




이명령 은 ~로 끝나는 파일을 모두 삭제 한다. 

2.2.9 파일 이름변 경하기 

Git 은 다른 VCS 시스 템과는 달리 파일 이름의 변 경이나 파일의 이동을 명시격 으로관 리하지 않 는다. 
다시 말해서 파일 이름이 변경 됐다는 별도의 정보를 저 장하지 않 는다. Git 은 똑 똑해서 굳이 파일 이름 
이 변경되 었다는 것을추 격하지 않아 도아는 방법이 있다. 파일의 이름이 변경된 것을 Git 이 어떻게 알 
아 내는지 살펴 보자. 

이렇게 말하고 Git 에 m 명렁이 있는 게 좀이 상하겠 지만， 아래와 같이 파일 이름을 변경할 수 있다: 
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$ git mv file_from file_to 



2.3 절 커 밋히스 토리조 회하기 



잘 동작 한다. 이 명렁을 실 행하고 Git 의 상태를 확인 해보면 Git 은 이름이 바뀐 사실을 알고 있다: 

$ git mv README.txt README 
$ git status 
On branch master 
Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

renamed: README.txt -> README 



사실 git 명렁 은아래 명렁 어들을 수행한 것과완 견히똑 같다: 

$ mv README.txt README 
$ git rm README.txt 
$ git add README 



git nw 는일종 의단측 명렁어 이다. 이명렁 으로파 일이름 을바꿔 도되고 nw 명렁 으로파 일이름 을직집 
바꿔도 된다. 단지 Git 의 mv 명렁 은편 리하게 명렁을 세번실 행해주 는것뿐 이다. 어떤도 구로이 름을바 
꿔도 상관 없다. 중요한 것은 이름을 변 경하고 나서 꼭 rm/add 명렁을 실 행해야 한다는 것뿐 이다. 

2.3 커 밋히스 토리조 회하기 

새로 저 장소를 만 들어서 S 번 커밋을 했을 수도 있고， 커밋 히스 토리가 있는 저 장소를 Clone 했을 수도 
있다. 어쨌든 가끔 저 장소의 히스 토리를 보고 심을 때가 있다. Git 에는 히스 토리를 조 회하는 명 렁어인 

git log 가 있다. 

이 예제 에서는 simplegit 이라는 매우 단순한 프로 젝트를 사용 한다. simp ᅵ egit 은 Git 을 설명 하는데 자 
주 사 용하는 예 제다. 아래와 같이이 프로 젝트를 Clone 한다: 

git clone git://github.ccim/schacon/simplegit— pr— 



이 프 로젝트 디롁토 리에서 git log 명 렁을실 행하면 아래 와같이 출력 된다: 

$ git log 

commit ca82a6dff81 7ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail . com) 
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Date: Mon Mar 17 21:52:11 2008 -0700 

changed the version number 

commit 085bb3bcb608e1 e8451 d4b2432f8ecbe6306e7e7 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Sat Mar 15 16:40:33 2008 -0700 

removed unnecessary test code 

commit a1 1 bef06a3f659402fe7563abf99ad00de2209e6 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Sat Mar 15 10:31:28 2008 -0700 

first commit 



특별한 아규먼 트없이 git log 명 렁을실 행하면 저장소 의커밋 히스토 리를시 간순으 로보여 준다. 즉， 
가장 최근의 커밋이 가 장먼저 나 온다. 그리고 이어서 각 커밋의 SHA-1 체 크섬， 저자 이름， 저 자이메 
일， 커밋한 날짜， 커밋 메시지 를보여 준다. 

원하는 히스토 리를검 색할수 있도록 git log 명 렁은매 우다양 한웁션 을지원 한다. 여 기에서 는자주 
사용하 는옵션 을설명 한다. 

-P 가가장 유용한 옵션 중 하 나다. -P 는 각 커밋의 diff 결과를 보여 준다. 게다가 -2 는 최근 두 개의 결과 
만 보여주 는웁션 이다: 

$ git log — p -2 

commit ca82a6dff81 7ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Mon Mar 17 21:52:11 2008 -0700 

changed the version number 

diff —git a/Rakefile b/Rakefile 
index a874b73. .8f94139 100644 
— a/Rakefile 
+++ b/Rakefile 

@@ —5,7 +5,5 @@ require 1 rake/gempackagetask 1 
spec = Gem: :Specification.new do ！ s ！ 







name = 


= "simplegit" 






version = 


: "0.1.0" 






version = 


: "0.1.1" 






author = 


= "Scott Chacon" 






email = 


= "schacon@gee-mail 
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2.3 절 커 밋히스 토리조 회하기 



commit 085bb3bcb608e1 e8451 d4b2432f8ecbe6306e7e7 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Sat Mar 15 16:40:33 2008 -0700 

removed unnecessary test code 

diff —git a/lib/simplegit.rb b/lib/simplegit.rb 
index a0a60ae. .47c6340 100644 

- a/lib/simplegit.rb 
+++ b/lib/simplegit.rb 

@@ -18,8 +18,3 @@ class SimpleGit 
end 

end 

-if $0 = _FILE_ 

- git = SimpleGit. new 

- puts git. show 
-end 

\ No newline at end of file 



이 옵션은 직접 diff 를 실행한 것과 같은 결과를 출 력하기 때문에 동료가 무엇을 커밋 했는지 리 뷰하고 
빨리 조회 하는데 유용 하다. 

가끔은 diff 결과를 줄 단위로 보기 보다는 단어 단위로 보는 것이 좋을 때도 있다. git log -p 와 같은 명 
렁에 -word-dif f 옵션을 사 용하면 즐 단위 대신 단어 단위로 변경 사항을 보여 준다. 단어 단위로 다른 부 
분을 확 인하는 것은 소스코 드에는 별로 유 용하지 않다. 책이나 에세이 같이 문장이 긴 글을쏠 때는 단 
어 단위로 보는 것이 편 하다. -word-diff 웁션은 다음과 같이 사용 한다: 

$ git log -U1 —word-diff 

commit ca82a6dff81 7ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Mon Mar 17 21:52:11 2008 -0700 

changed the version number 

diff —git a/Rakefile b/Rakefile 
index a874b73. ,8f94139 100644 
— a/Rakefile 
+++ b/Rakefile 

@@ -7,3 +7,3 @@ spec = Gem ： ： Specification . new do ！ s ！ 
s . name = "simplegit" 
s. version = [-"0.1 .0"-]{+"0.1 .1"+} 
s. author = "Scott Chacon" 
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위의 예제는 줄 단위로 보 여주는 일 반격인 diff 와 좀 다 르다. 줄 안에서 변경한 부분을 단어 단위로 표 
시 한다. 추가한 단어는 {+ +} 기 호가둘 러싸고 삭제한 단어는 [- -] 기호 가들러 싼다. diff 는기 본격으 
로 다른 줄과 위아래 줄을 포 함해서 3 줄을 보여 준다. 줄 단위가 아니라 단어 단 위로비 교해서 볼 때는 굳 
이 3 줄을 다 볼 필요가 없다. 예 제에서 처럼 -U1 옵션을 주면 해당 줄만 보여 준다. 
또 git log 명 령에는 히스 토리의 통계를 보 여주는 옵션도 있다. -stat 옵 션으로 각 커밋의 통계 정보 
를조 회할수 있다: 



$ git log —stat 

commit ca82a6dff81 7ec66f44342007202690a93763949 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Mon Mar 17 21:52:11 2008 -0700 

changed the version number 

Rakefile ！ 2 +— 

1 file changed, 1 insertion(+) / 1 deletion(-) 

commit 085bb3bcb608e1 e8451 d4b2432f8ecbe6306e7e7 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Sat Mar 15 16:40:33 2008 -0700 

removed unnecessary test code 

lib/simplegit.rb ！ 5 

1 file changed, 5 deletions(-) 

commit a1 1 bef06a3f659402fe7563abf99ad00de2209e6 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Sat Mar 15 10:31:28 2008 -0700 



first commit 



README 
Rakefile 

lib/simplegit.rb 
3 files changed, 54 insertions(+) 



6 ++++++ 
23 +++++++++++++++++++++++ 
25 ++++++++++++++++H 



이 결 과에서 -stat 옵션 은어떤 파일이 수정됐 는지， 얼마나 많은 파일이 변경됐 는지， 또 얼마나 많은 
줄을추 가하거 나삭제 했는지 보여 준다. 요 약정보 는가장 뒤쪽에 보여 준다. 

다른또 유용한 옵션은 "pretty 옵션 이다. 이옵션 을통해 log 의 내 용을보 여줄때 기 본형식 이외에 여 
러 가지 중에 하나를 선택할 수 있다. oneline 옵션은 각 커밋을 한 줄로 보여 준다. 이 옵션은 많은 커밋 
을 한 번에 조회할 때 유용 하다. 추가로 short, full, fuller 옵선도 있는데 이것은 정보를 조금씩 가감해 
서 보여 준다: 
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2.3 절 커 밋히스 토리조 회하기 



$ git log — pretty=oneline 






Ca82a6dff817ec66f44342007202690a93763949 


changed the version 




085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 


removed unnecessary 


test code 


a1 1 bef06a3f659402fe7563abf99ad00de2209e6 


first commit 





가장 개밌는 옵션은 format 옵션 이다. 나만의 포 맷으로 결과를 출 력하고 싶을 때 사용 한다. 특히 결과 
를 다른 프로그 램으로 파싱 하고자 할 때 유용 하다. 이 옵션을 사 용하면 포맷을 정 확하게 일 치시길 수 있 
기 때문에 Git 을새 버 견으로 바꿔도 결과 포맷이 바뀌지 않 는다: 



$ git log 


ᅳᅳ pretty=format: "%h - %an, %ar ： %s" 




ca82a6d - 


Scott Chacon, 11 months ago ： changed the version 


number 


085bb3b - 


Scott Chacon, 11 months ago ： removed unnecessary 


test code 


a11bef0 - 


Scott Chacon, 11 months ago ： first commit 





표 2-1 형 식에서 사 용하는 유용한 옵산 



Option Description of 0 니 tput 
%H Commit hash 
%h Abbreviated commit hash 
%T Tree hash 

%t Abbreviated tree hash 

%P Parent hashes 

%p Abbreviated parent hashes 

%an Author name 

%ae Author e-mail 

%ad Author date (format respects the ― date= option) 

%ar Author date, relative 

%cn Committer name 

%ce Committer email 

%cd Committer date 

%cr Committer date, relative 

%s Subject 



저자 (Author) 와 커미터 (Committer) 를 구 분하는 것이 조금 이상해 보일 수 있다. 저자는 원래 작업 
을 수행한 원작 자이고 커 밋터는 마지 막으로 이 작업을 격용 한사람 이다. 만약 당신이 어떤 프로 젝트에 
패치를 보냈고 그 프로 젝트의 담 당자가 패치를 격용 했다면 두 명의 정보를 모두 알 필요가 있다. 그래서 
이 경우 당신이 저자고 그 담 당자가 커미 터다. 5 장에서 이 주제에 대해 차세히 다룰 것 이다. 
oneline 과 fooiat 웁션은 -graph 웁션과 함께 사용할 때 더 빛 난다. 이 명렁은 브 탠치와 머지 히 스토리 
를보 여주는 아스키 그래프 를출력 한다. 이 명렁을 Grit 프로 젝트저 장소에 서사용 해보면 아래와 같다: 
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$ git log — pretty=format: "%h %s" ―— graph 

* 2d3acf9 ignore errors from SIGCHLD on trap 

* 5e3ee1 1 Merge branch 'master' of git://github.com/dustin/grit 
!\ 

！ * 420eac9 Added a method for getting the current branch. 

* ！ 30e367c timeout code and tests 

* ！ 5a09431 add timeout protection to grit 

* ！ e1 193f8 support for heads with slashes in them 
！/ 

* d6016bc require time for xmlschema 

* 11d191e Merge branch 'defunkt' into local 



git log 명령 의기본 적인옵 션과출 력물의 형식에 관런된 옵션을 살펴보 았다. git log 명령은 앞서살 
펴본 것보다 더 많은 옵선을 지원 한다. 표 2-2 는 지금 설명한 것과 함깨 유 용하게 사용할 수 있는 옵션 
이다. 각옵 션으로 어떻게 log 명 렁을제 어할수 있는지 보여 준다. 



옵션 설명 

-P 각 커밋에 적용된 패치를 보여 준다. 

— word-diff diff 결과를 단어 단위로 보여 준다. 

-stat 각 커 밋에서 수정된 파일의 통계 정보를 보여 준다. 

-shortstat 、- -stat、 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여 준다. 
-name-only 커밋 정보 중에서 수정된 파일의 목록만 보여 준다. 

-name-status 수정된 파일의 목록을 보여즐 뿐만 아니라 파일을 추가한 것 인지, 수정한 것 인지, 삭 
제한 것 인지도 보여 준다. 

-abbrev-commit 40 자 짜리 SHA-1 체 크섬을 전부 보 여주는 것이 아니라 처음 몇 자만 보여 준다. 
-relative-date 정확한 시간을 보 여주는 것이 아니라 、2 주전、 처럼 상 대적인 형 식으로 보여 준다. 
-graph 브 랜치와 머지 히 스토리 정 보까지 아스키 그 래프로 보여 준다. 

—pretty 지정한 형 식으로 보여 준다. 이 몹 션에는 oneline, short, full, fuller, format 이 있 
다. format 은 원하는 형 식으로 출력 하고자 할 때 사용 한다. 

—― oneline " —― pretty=oneline —― abbrev-commit" §키 ᄉ| "피 (■ 히" c h 



2.3.1 조회제 한조건 

출력 형식과 관련된 옵션을 살펴 봤지만 git log 명렁은 조회 범위를 제 한하는 옵 션들도 있다. 히스토 
리 견부가 아니라 부분만 조회 한다. 이미 최근 두 개만 조 회하는 -2 옵션은 살펴 봤다. 실제 사 용법은 - 
< n > 이고 n 은 최근 n 개의 커밋을 의미 한다. 사실 이 옵션은 잘 쓰이지 않 는다. Git 은 기본 격으로 출력을 
pager 류의 프로 그램을 거처서 내보내 므로한 번에 한페 이지씩 보여 준다. 

반면 -since 나 -until 같은 시간을 기 준으로 조 회하는 옵션은 매우 유용 하다. 지난 2 주 동안 만 들어진 
커 밋들만 조 회하는 명령은 아래와 같다: 
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$ git log —since=2. weeks 



2.3 절 커 밋히스 토리조 회하기 



이옵션 은다양 한형식 을지원 한다. 2008— 01— 15 같이 정확한 날짜도 사용할 수있고 2 years 1 day 3 
minutes ago 같이 상 대적인 기간 을사용 할수도 있다. 

또 다른 기준도 있다. -author 옵 션으로 저자를 지 정하여 검색할 수도 있고 —grep 옵 션으로 커밋 메시 

지에서 키 워드를 검색할 수도 있다 (author 와 grep 옵션을 함께 사 용하면 모두 만 족하는 커밋을 찾는 
다). 

grep 옵선을 여러개 사 용하면 그중하 나이상 만 족하는 커밋을 찾 는다. 모두 만 족하는 커밋을 찾 으려면 

-all-match 옵션을 추 가해야 한다. 

마 지막으 로파일 경 로로검 색하는 옵션이 있는데 이 것도정 말유용 하다. 디 텍토리 나파일 이름 을사용 
하여그 파일이 변경된 log 의 결 과를검 색할수 있다. 이 옵션 은-- 와함깨 경 로이름 을사용 하는데 명령 
어 끝부분 에쓴다 (역 주， git log - pathl path2). 

표 2-3 은조회 범 위를제 한하는 옵션들 이다. 

몹션 설명 

-(n) 최근 n 개의 커밋만 조회 한다. 
-since, -after 명시한 날짜 이후의 커밋만 검색 한다. 
-until, -before 명시한 날짜 이전의 커밋만 조회 한다. 
-author 입력한 저자의 커밋 만보여 준다. 
-committer 입 력한커 미터의 커밋 만보여 준다. 

아래 예제는 2008 년 10 월에 Junio Hamano 가커 밋한히 스토리 를조회 하는것 이다. 그 중에서 테스 
트 파일을 수정한 커밋 중에서 머지 커밋이 아닌 것들만 조회 한다: 



$ git log — pretty="%h - %s" ~author=gitster — since="2008-10-01 " \ 

— before="2008-11-01" —no-merges -- t/ 
5610e3b - Fix testcase failure when extended attribute 
acd3b9e - Enhance hold— lock_file_for— {update, append}( ) 
f563754 - demonstrate breakage of detached checkout wi 
d1a43f2 - reset —hard/read-tree ―— reset — u: remove un 
51a94af - Fix "checkout —track -b newbranch" on detac 
b0ad11e - pull: allow "git pull origin $something:$cur 



총 2 만여 개의 커밋 히스토 리에서 이 명령의 검색 조건에 만 족하는 것은 단 6 개 였다. 
2.3.2 GUI 도구로 히스 토리를 시각 화하기 

GUI 도구로 커 밋히스 토리를 시각 화하고 싶다면 gitk 를 사용할 수 있다. gitk 는 Td/Tk 프로그 램이고 
git log 명 령을시 각화해 주는도 구다. gitk 는 git log 명령이 지 원하는 필터링 옵션 을거의 모두 지원한 
다. 프 로젝트 디텍토 리에서 gitk 를실 행하면 그림 2-2 처럼 보일 것 이다. 

위쪽 반을 차 지하는 윈도 에서는 히스 토리를 그 래프로 예쁘게 보여 준다. 아래쪽 반을 차 지하는 윈도는 
diff 결 고ᅡ를 보여 주는데 위쪽 윈 도에서 선택한 커밋에 대한 diff 결 고ᅡ를 보여 준다. 
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2.4 되 돌리기 

일을 하 다보면 모든 단 계에서 어떤 것은 되 돌리고 (Undo) 심을 때가 있다. 이 번에는 우리가 한 일을 되 
돌리는 방법을 살펴볼 것 이다. 한 번 되 돌리면 복구할 수 없어서 주 의해야 한다. Git 을 사 용하면 우리가 
한 실수를 복 구하지 못할 것은 거의 없지만 되돌 리기는 복구할 수 없다. 

2.4.1 커밋수 정하기 

종종 완료한 커밋을 수 정해야 할 때가 있다. 너무 일찍 커 밋했거 나어떤 파일을 빼 먹었을 때 그리고 커 

밋 메 시지를 잘못 격었을 때 하게 된다. 다시 커 밋하고 싶으면 -amend 옵선 을사용 한다: 
$ git commit —amend 



이 명렁은 Staging Area 를 사 용하여 커밋 한다. 만약 마지 막으로 커 밋하고 나서 수정한 것이 없다면 
(커 밋하 자마자 바로 이 명령을 실 행하는 경우) 조금 견에 한 커밋 과모든 것이 같다. 이때는 커밋 메시 
지 만수정 한다. 

편집 기가실 행되면 이전 커밋 메 시지가 자동으 로포함 된다. 메시 지를수 정하지 않고그 대로커 밋해도 
기존 의커밋 을덮어 쓴다. 

커밋을 했는데 Stage 하는 것을 깜 빡하고 빠트린 파일이 있으면 아래와 같이 고칠 수 있다: 

$ git commit -m 1 initial commit 1 
$ git add forgotten— file 
$ git commit —amend 

여기서 실행한 명렁어 3 개는 모두 하나의 커 밋으로 기록 된다. 두 번째 커밋은 첫 번째 커밋을 덮어 쓴다. 
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2.4 절 되 돌리기 



2.4.2 파일 상태를 Unstage 로 변 경하기 

다음은 Staging Area 와 워킹 디 텍토리 사이를 넘 나드는 방법 을설명 한다. 두 영역의 상태를 확인할 
때마다 변경된 상태를 되 돌리는 방법을 알 려주기 때문에 매우 편리 하다. 예를 들어 파일을 두 개 수정하 
고서 따 로따로 커밋 하려고 했 지만， 실수로 git add * 라고 실행해 버 렀다. 두 파일 모두 Staging Area 
에 들어 있다. 이제 들 중 하나를 어떻게 끼 낼까? 우선 git status 명 령으로 확인해 보자: 



$ git add . 




$ git status 




On branch master 




Changes to be committed: 




(use "git reset HEAD <file>. . . " to u 


nstage) 


modified: README.txt 




modified : benchmarks . rb 





Changes to be commited 밑에 git reset HEAD <file〉. . . 이라 는문장 을볼수 있다ᅳ 이 명 렁으로 Unstage 

상태로 변경할 수 있다. benchmarks.rb 파일을 Unstage 상태로 변경해 보자: 



$ git reset HEAD benchmarks.rb 
Unstaged changes after reset: 
M benchmarks.rb 
$ git status 
On branch master 
Changes to be committed: 

(use "git reset HEAD <f ile>. . . " to unstage) 

modified: README.txt 

Changes not staged for commit: 
(use "git add <file>. . . " to update what will be committed) 
(use "git checkout ― <file>. . . " to discard changes in working directory) 

modified ： benchmarks . rb 

명 렁어가 낯설게 느껴질 수도 있지만 잘 동작 한다. benchmarks.rb 파일은 Unstage 상태가 됐다. 
2.4.3 Modified 파일되 돌리기 

어떻게 해야 benchmarks.rb 파일을 수 정하고 나서 다시 되들릴 수 있 을까? 그 러니까 최근 커밋된 
버 견으로 (아 니면 처음 Clone 했을 때처럼 워킹 디롁 토리에 처음 Checkout 한 그 내용 으로) 되 돌리는 
방법이 무 얼까? git status 명렁이 친 결하게 알려 준다. 바 로위에 있는예 제에서 Unstaged 부 분을보 
자: 
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Changes not staged for commit: 
(use "git add <file>. . . " to update what will be committed) 
(use "git checkout ― <file>. . . " to discard changes in working directory) 

modified ： benchmarks . rb 



위의 메 시지는 수정한 파일을 되 돌리는 방법을 폐 정 확하게 알 려준다 (적 어도 Git 1 .6. 1 이후 버 전부터 
는그 렇다. 만약 예견 것을 아직 사 용하고 있으면 업그레 드하는 것이 좋다. 편 의성이 많이 개선됐 다). 

알려주 는대로 한번해 보자: 

$ git checkout ―— benchmarks. rb 
$ git status 
On branch master 
Changes to be committed: 
(use "git reset HEAD <f ile>. . . " to unstage) 

modified: README.txt 



정상 적으로 복원된 것을 알 수 있다. 하지만 이명령 은꾀! 위험한 명렁 이라는 것을 알아야 한다. 수정 이 
견의 파일로 덮 어썼기 때문에 수 정했던 내용은 견부 사라 진다. 수정한 내용이 진짜 마음에 들지 않을 때 
에 만사용 하자. 정말 이렇게 삭 제해야 한다면 Stash 와 Branch 를사용 하자. 다음 장에서 다 루는이 방 
법들이 휠썬 낫다. 

Git 으로 커 밋한 모든 것은 언제나 복구할 수 있다. 삭제한 브 랜치에 있었던 것도 -amend 옵 션으로 다시 
커밋한 것도 복구할 수 있다 (자 세한 것은 9 장에서 다툰다 ). 하 지만, 커 밋하지 않고 잃 어버린 것은 결대 
로되 돌릴수 없다. 



2.5 리모트 저장소 

리모트 저 장소를 관리할 줄 알아야 다른 사람과 함께 일할 수 있다. 리모트 저 장소는 인터 넷이나 네트 
워크 어 딘가에 있는 저 장소를 말 한다. 저장소 는여러 개가 있을 수 있는데 어떤 저 장소는 읽고 쓰기 모 
두 할수있 고어떤 저 장소는 읽기 권한만 있을 수도 있다. 간단히 말해서 다른 사 람들과 함께 일 한다는 

것은 리모트 저장소 를관리 하면서 데 이터를 거기에 Push 하고 Pull 하는것 이다. 리 모트저 장소 를관리 
한다는 것은 저 장소를 추가, 삭 제하는 것뿐만 아니라 브 랜치를 관 리하고 추 격할지 말지 등을 관 리하는 
것을 말 한다. 이 번에는 리모트 겨 장소를 관 리하는 방법에 대해 설명 한다. 



2.5.1 리 모트저 장소확 인하기 

git remote 명 령으로 현재 프로 젝트에 등록된 리모트 저 장소를 확인할 수 있다. 이 명령은 리모트 저장 

소의 단축 이름을 보여 준다. 저 장소를 Clone 하면 origin 이라는 리모트 저장 소가자 동으로 등 록되기 때 
문에 origin 이라 는이름 을볼수 있다: 
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$ git clone git ： // git hub . com/ schacon/ ticgit . git 




Cloning into 1 ticgit 1 . . . 




remote: Reusing existing pack: 1857, done. 




remote: Total 1857 (delta 0), reused 0 (delta 0) 




Receiving odj ects • { lob// lob/;, kid i I . wu kid/s, done . 




Kesoi viny aeitas • i \ 1 1 li i i l) , uone . 




Checking connectivity . . . done . 




$ cd ticgit 




$ git remote 




origin 




-v 옵션을 주어 단축 이름과 URL 을 함께 볼 수 있다: 


$ git remote -v 




origin git://github.com/schacon/ticgit .git (fetch) 




origin git://github.com/schacon/ticgit .git (push) 









리모트 저장소 가여러 개 있다면 이 명렁은 견부 보여 준다. 내 Grit 저장 소에서 실 행하면 아래와 같이 
&력 한다: 



$ cd grit 

$ git remote -v 

bakkdoor git ://github.com/bakkdoor/grit.git 
cho45 git ://github.com/cho45/grit.git 
defunkt git ： I /github . com/def unkt/grit . git 
koke git://github.com/koke/grit .git 
origin git@github . com ： moj ombo/grit . git 



이렇게 리모트 저장소 가여러 개가등 록되어 있으면 다른 사람이 기여 한내용 (Contributions) 을쉽게 
가져올 수 있다. 그리고 origin 만 SSH URL 이기 때문에 origin 에만 Push 할 수 있다 (4 장에서 좀 더 자 
세히 다툰다 ). 

2.5.2 리 모트저 장소추 가하기 

이견 절 에서도 리모트 저 장소를 추 가하는 것에 대해 설명했 었지만 수박 겉핥기 식으로 살 펴봤을 뿐이었 
다. 여기 에서는 리모트 저 장소를 추 가하는 방법을 자 세하게 설명 한다. 쉽게 새 리모트 저 장소를 추가할 

수 있는데 git remote add [단축 이름] [url] 명렁 을실행 한다: 

$ git remote 
origin 
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$ git remote add pb git://github.com/paulboone/ticgit .git 
$ git remote -v 

origin git://git^b.cctm/schacon/ticgi1:.git 
pb git://github.com/paulboone/ticgit .git 



이제 URL 대신에 스트링 P b 를 사용할 수 있다. 예를 들어 로컬 저장 소에는 없지만 Paul 의 저 장소에 있 
는 것을 가져 오려면 아래과 같이 실행 한다: 

$ git fetch pb 

remote: Counting objects: 58, done. 

remote: Compressing objects: 100% (41/41), done. 

remote: Total 44 (delta 24), reused 1 (delta 0) 

Unpacking objects: 100% (44/44), done. 

From git://github.com/paulboone/ticgit 

* [new branch] master -> pb/master 

* [new branch] ticgit -> pb/ticgit 

로 컬에서 pb/master 가 Paul 의 master 브탠치 이다. 이것을 로컬브 탠치중 하나에 머지 하거나 체크아 

옷하여 브탠치 내용을 자세히 확인할 수 있다. 

2.5.3 리 모트저 장소를 Pull 하거나 Fetch 하기 

앞서 설명 했듯이 리모 트저장 소에서 데이터 를가져 오려면 간단히 아래 와같이 실행 한다: 

$ git fetch [remote-name] 

이 명령은 로 컬에는 없 지만, 리모트 저장 소에는 있는 데 이터를 모두 가겨 온다. 그리고 나면 리모트 저 
장소의 모든 브 탠치를 로 컬에서 집근할 수 있어서 언 제든지 머지를 하거나 내용을 살펴볼 수 있다 (우리 
는 3 장에서 브탠 치를사 용하는 방법에 대해 좀 더 자세히 설명할 것이다 ). 

저 장소를 Clone 하면 명렁은 자 동으로 리모트 저 장소를 origin 이라는 이 름으로 추가 한다. 그래서 나 

중에 git fetch origin 을 실 행하면 Clone 한 이후에 (흑은 마지 막으로 가겨온 이 후에) 수정된 것을 모두 
가져 온다. fetch 명령은 리모트 겨 장소의 데 이터를 모두 로컬로 가져오 지만， 자 동으로 머 지하지 않는 

다. 그래서 당신이 로 컬에서 하던 작 업을정 리하고 나서 수 동으로 머 지해야 한다. 

그낭 쉽게 git pull 명 렁으로 리모트 저장소 브탠 치에서 데 이터를 가겨올 뿐만 아 니라자 동으로 로컬 
브 랜치와 머 지시길 수 있다. 먼저 git clone 명렁은 자 동으로 로걸의 master 브 랜치가 리모트 저장소 
의 master 브 탠치를 추격 하도록 한다 (물론 리모트 저 장소에 master 브 랜치가 있다고 가정에 서). 그 
리고 git pull 명령은 Clone 한서 버에서 데 이터를 가져오 고그데 이터를 자동으 로현재 작업하 는코드 
와 머지시 킨다. 

2.5.4 리 모트저 장소에 Push 하기 

프 로젝트 를공유 하고싶 을때리 모트저 장소에 Push 할수 있다. 이 명령은 git push [리 모트 저장소 이 
름] [브 랜치 이름] 으 로단순 하다. master 브 탠치를 origin 서버에 Push 하려면 (다 시말 하지만 Clone 
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하면 보통자 동으로 origin 이름이 생성 된다) 아래 와같이 서버에 Push 한다: 



$ git push origin master 




이 명렁은 Clone 한 리모트 저 장소에 쓰기 권한이 있고， Clone 하고 난 이후 아무도 리모트 저 장소에 
Push 하지 않았을 때만 사용할 수 있다. 다시 말해서 Clone 한 사람이 여러 명있을 때, 다른 사람이 
Push 한 후에 Push 하려고 하면 Push 할 수 없다. 먼저 다른 사람이 작업한 것을 가 져와서 머지한 후에 
Push 할수 있다. 3 장에서 서버에 Push 하는 방법에 대해 자세히 설명할 것 이다. 

2.5.5 리 모트저 장소살 펴보기 

(역 주， 이 결은 최신 버전의 Git 이 출 력하는 메 시지와 조금 다르다 .) 

git remote show [리 모트 저장소 이름] 명 령으로 리모트 저장소 의구체 격인정 보를확 인할수 있다. 
origin 같은 단축이 름으로 이 명렁을 실 행하면 아래와 같은 정보를 볼 수 있다: 



$ git remote show origin 




* remote origin 




URL: git://github.a)m/schacon/ticgii:.git 




Remote branch merged with 'git pull' while o 


n branch master 


master 




Tracked remote branches 




master 




ticgit 





리 모트저 장소의 URL 과추 격하는 브랜치 를출력 한다. 이 명령은 git pull 명 렁을실 행할때 master 
브 랜치와 머지할 브 탠치가 무 엇인지 보여 준다. git pull 명령은 리모트 저장소 브 탠치의 데 이터를 모 
두 가 져오고 나서 자 동으로 머지할 것 이다. 그리고 가져온 모든 리모트 저장소 정보도 출력 한다. 
좀 더 Git 을 열심히 사 용하게 되면 git remote show 명령은 더 많은 정보를 보여줄 것 이다. 여 러분도 언 
젠가는 아래와 같은 메시지 (역 주, 다수의 브 탠치를 사 용하는 메시지 ) 를볼 날이 을 것 이다. 

$ git remote show origin 
* remote origin 

URL: git@github.a5m:defunkt/github.git 

Remote branch merged with 'git pull' while on branch issues 
issues 

Remote branch merged with 'git pull' while on branch master 
master 

New remote branches (next fetch will store in remotes/origin) 
caching 

Stale tracking branches (use 'git remote pr 니 ne') 
libwalker 
walker2 
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Tracked remote branches 
acl 
apiv2 

dashboard2 
issues 
master 
postgres 



Local branch pushed with 'git push 
master: master 




브탠 치명을 생 락하고 git push 명렁을 실행할 때 어떤 브탠치 가어떤 브 탠치로 Push 되는지 보여 준다. 
또 아직 로컬로 가 겨오지 않은 리모트 저 장소의 브 탠치는 어떤 것들이 있 는지， 서버 에서는 삭제 됐지만 
아직 가지고 있는 브 탠치는 어떤 것 인지， git pull 명렁을 실 행했을 때 자 동으로 머지할 브탠치 는어떤 

것이 있는지 보여 준다. 



2.5.6 리모트 저장소 이름을 바 꾸거나 리모트 저 장소를 삭 제하기 

git remote rename 명렁으 로리모 트저장 소의이 름을변 경할수 있다. 예 를들어 pb 를 paul 로변 경하려 
면 git remote rename 명 렁을사 용한다 ： 

$ git remote rename pb paul 

$ git remote 

origin 

paul 



리모트 저 장소의 브탠치 이름도 바 뀐다. 여 태까지 pb/master 로 리모트 저장소 브탠치 를사용 했으면 이 
제는 paul/master 라고 사 용해야 한다. 

리모트 저 장소를 삭 제해야 한다면 git remote rm 명렁을 사용 한다. 서버 정 보가바 뀌었을 때， 더는 별 
도의 미러가 필 요하지 않을 때， 더는 기 여자가 활 동하지 않을 때 필요 하다: 

$ git remote rm paul 
$ git remote 
origin 



2.6 태그 

다른 VCS 처럼 Git 도 태그를 지원 한다. 사 람들은 보통 릴 리즈할 때 사 용한다 (v1 .0, 등등 ). 이 번에는 
태그를 조 회하고 생 성하는 법과 태그의 종류를 설명 한다. 

2.6.1 태그조 회하기 

우선 git tag 명령으 로이미 만 들어진 태그가 있는지 확인할 수 있다: 
38 
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$ git tag 
v0.1 
v1 .3 



이 명령은 알파벳 순서로 태그를 보여 준다. 사실 순서는 별로 중요한 게 아 니다. 

검색 패턴을 사 용하여 태그를 검색할 수 있다. Git 소스 저 장소는 240 여 개의 태그가 있다. 만약 1 .4.2 

버전의 태 그들만 검 색하고 싶으면 아래와 같이 실행 한다: 

$ git tag -1 VI .4.2.*' 
v1 .4.2.1 
v1 .4.2.2 
v1 .4.2.3 
v1 .4.2.4 



2.6.2 태그 불이기 

Git 의 태그는 Lightweight 태그와 Annotated 태그로 두 종류가 있다. Lightweight 태그는 브탠치 
와 비 숫한데 브탠 치처럼 가 리키는 지점을 최신 커 밋으로 이동 시키지 않 는다. 단순히 특정 커밋에 대한 
포 인터일 뿐 이다. 한편, Annotated 태그는 Git 데 이터베 이스에 태그를 만든 사람의 이름， 이 메일과 태 
그를 만든 날짜, 그리고 태그 메 시지도 저장 한다. 또 GPG(GNU Privacy Guard) 로 서명할 수도 있다. 
이 모든 정보를 저장 해둬야 할 때에만 Annotated 태그를 추천 한다. 그낭 다른 정보를 겨 장하지 않는 
단순한 태그가 필요 하다면 Lightweight 태 그를사 용하는 것이 좋다. 

2.6.3 Annotated 태그 

Annotated 태그를 만드는 방법은 간단 하다. tag 명령을 실행할 때 -a 옵션을 추가 한다: 

$ git tag -a v1 A — m 'my version 1 .4' 

$ git tag 

V0.1 

v1.3 

v1.4 



- m 웁 선으로 태그를 저장할 때 메 시지를 함께 저장할 수 있다. 명렁을 실행할 때 메시지 를 입 력하지 않 

으면 Git 은편 집기를 실행시 킨다. 

git show 명 렁으로 태그 정보와 커밋 정보를 모두 확인할 수 있다: 

$ git show v1 .4 
tag v1 .4 

Tagger: Scott Chacon <schacon@gee-mail . com) 
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Date: Mon Feb 9 14:45:11 2009 -0800 
my version 1 A 

commit 1 5027957951 b64cf874c3557a0f3547bd83b3ff6 
Merge: 4a447f7. . . a6b4c97. . . 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Sun Feb 8 19:02:46 2009 -0800 



Merge branch 'experiment 




커밋 정 보를보 여주기 견에 먼저 태그를 만든 사람이 누구 인지, 언제 태그를 만들었 는지， 그리고 태그 
메시 지가무 엇인지 보여 준다. 

2.6.4 태 그에서 명하기 

GPG 개 인키가 있으면 태그에 서명할 수 있다. 이 때에는 -a 옵션 대신 -s 를사용 한다: 

$ git tag -s v1 . 5 -m 'my signed 1.5 tag 1 
You need a passphrase to unlock the secret key for 
user: "Scott Chacon <schacon@gee-mail . com>" 
1024-bit DSA key, ID F721C45A, created 2009-02-09 



이 태그에 git show 를 실 행하면 GPG 서명 도볼수 있다: 

$ git show v1 . 5 
tag v1 .5 

Tagger: Scott Chacon <schacon@gee-mail . com) 
Date: Mon Feb 9 15:22:20 2009 -0800 

my signed 1 .5 tag 

BEGIN PGP SIGNATURE 

Version: GnuPG v1 .4.8 (Darwin) 

iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggGQf0QYiQBwgySN 

Ki0An23eAVUCAi37Ox6ZEtK+NvZAj82/ 

=Wry] 

END PGP SIGNATURE 

commit 1 5027957951 b64cf874c3557a0f3547bd83b3ff6 
Merge: 4a447f7... a6b4c97... 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Sun Feb 8 19:02:46 2009 -0800 
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감시 후에 서명한 태그를 검 증하는 방법도 설명 한다. 

2.6.5 Lightweight 태그 

Lightweight 태그 는기본 격으로 파일에 커밋체 크심을 저 장하는 것뿐 이다. 다른 정보는 저 장하지 않 
는다. Lightweight 태그를 만들 때에는 -a， -s, -m 옵선을 사 용하지 않 는다: 

$ git tag v1 .4-lw 

$ git tag 

V0.1 

v1.3 

v1.4 

v1 .4-lw 

v1.5 



이 태그에 git show 를실 행하면 별도의 태그정 보를확 인할수 없다. 이 명렁은 단순히 커밋정 보만을 
보여 준다: 

$ git show v1 .4-lw 

commit 1 5027957951 b64cf874c3557a0f3547bd83b3ff6 
Merge: 4a447f7. . . a6b4c97. . . 
Author: Scott Chacon <schacon@gee-mail . com) 
Date: Sun Feb 8 19:02:46 2009 -0800 

Merge branch 'experiment' 



2.6.6 태그검 증하기 

git tag -v [태그 이름] 명령으 로서명 한태그 를검증 한다. 이 명렁은 GPG 를사 용하여 서명을 검증한 
다. 그래서 서 명자의 GPG 공개키 가필요 하다. 이 공 개키가 Keyring 에 있어 야만이 명령이 성공 적으로 
실행 된다: 

$ git tag -v v1 .4.2.1 

object 883653babd8ee7ea23e6a5c392bb739348b1eb61 
type commit 
tag vl.4.2.1 

tagger 3unio C Hamano <junkio@cox.net> 1158138501 -0700 
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GIT 1.4.2.1 

Minor fixes since 1 A. 2, including git— mv and git-http with alternates, 
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A 
gpg: Good signature from "3unio C Hamano <junkio@cox.net>" 
gpg: aka " [ j peg image of size 1513] " 

Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A 




만약 서 명자의 공 개키가 없으면 아래와 같은 메 시지를 출력 한다: 



gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A 
gpg: Can't check signature: public key not found 
error: could not verify the tag VI. 4. 2.1' 



2.6.7 나 중에태 그하기 

예전 커밋에 대 해서도 태그할 수 있다. 커밋 히스 토리는 아래와 같고: 



$ git log — pretty=oneline 

1 5027957951 b64cf874c3557a0f3547bd83b3ff6 

a6b4c97498bd301 d84096da251 c98a07c7723e65 

0d52aaab4479697da7686c1 5f77a3d64d91 651 90 

6d52a271eda8725415634dd79daabbc4d9b6008e 

0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc 

4682c3261057305bdd616e23b64b0857d832627b 

1 66ae0c4d3f420721 acbbl 1 5cc33848dfcc21 21 a 

9fceb02d0ae598e95dc970b74767f1 9372d61 af8 

964f16d36dfccde844893cac5b347e7b3d44abbc 

8a5cbc430f1a9c3dO0faaeffd07798508422908a 



Merge branch 'experiment' 
beginning write support 
one more thing 
Merge branch 'experiment' 
added a commit function 
added a todo file 
started write s 니 pport 
updated rakefile 
commit the todo 
updated readme 



"updated rakefile" 커밋을 v1 .2 로 태 그하지 못 했다고 해도 차후에 태그를 붙일 수 있다. 특정 커밋 
에 태 그하기 위해서 명렁의 끝에 커밋 체 크섬을 명 시한다 (긴 체크섬 을견부 사용할 필요는 없다) ： 



$ git tag —a v1 .2 -m 'version 1 .2' 9fceb02 



이제 아래와 같이 만든 태그를 확인 한다: 
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$ git tag 



V0 


1 


v1 




v1 




v1 


4 


v1 


4-lw 


v1 





$ git show v1 .2 
tag v1 .2 

Tagger: Scott Chacon <schacon@gee-mail . com) 
Date: Mon Feb 9 15:32:16 2009 -0800 

version 1 .2 

commit 9fceb02d0ae598e95dc970b74767f 1 9372d61 af8 
Author: Magnus Chacon <mchacon@gee-mail . com) 
Date: Sun Apr 27 20:43:35 2008 -0700 

updated rakefile 



2.6.8 태그공 유하기 

git push 명 렁은자 동으로 리모트 서버에 태 그를견 송하지 않 는다. 태그를 만들 었으면 서버에 별도로 
Push 해야한 다. 브탠치 를공유 하는것 과같은 방법으 로할수 있다. git push origin [태그 이름] 을실 
행 한다: 



$ git push origin v1 .5 

Counting objects: 50, done. 

Compressing objects: 100% (38/38) , done. 

Writing objects: 100% (44/44), 4.56 KiB, done. 

Total 44 (delta 18), reused 8 (delta 1) 

To git@github.com:schacon/simplegit .git 

* [new tag] v1 .5 -> v1 .5 



만약 한번에 태그를 여러개 Push 하고 싶으면 —tags 옵 선을추 가하여 git push 명렁 을실행 한다. 이 
명 렁으로 리모트 서버에 없는 태그를 모두 전송할 수 있다: 



$ git push origin —tags 

Counting objects: 50 , done. 

Compressing objects: 100% (38/38), done. 
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Writing objects: 100% (44/44), 4.56 KiB, done. 
Total 44 (delta 18), reused 8 (delta 1) 
To git@github . com: schacon/ simplegit.git 



* [n 


ew tag] 


V0 


1 -> V0.1 


* [n 


ew tag] 


v1 


2 -> v1.2 


* [n 


ew tag] 


v1 


4 -> v1 A 


* [n 


ew tag] 


v1 


4-lw -> v1 .4-lw 


* [n 


ew tag] 


v1 


5 -> v1.5 



누군가 저장 소에서 Clone 하거나 Pull 을 하면 모든 태그 정보도 함께 전송 된다. 

2.7 팁 과트릭 

Git 의 기초를 마치기 견에 Git 을 좀 더 쉽고 편 안하게 쏠 수 있게 만들어 줄 몇 가지 팁과 트릭도 설명한 
다. 이런 팁 없이 Git 을사용 하는사 람들도 많다. 우리는 이 책에서 이 팁을 다시 거 론하지 않고 이런 팁 
을 알고 있다고 가정 한다. 그래서 알고 있는 것이 좋다. 

2.7.1 자 동완성 

Bash 쉘을 쓰고 있다면 멋진 자 동완성 (Auto— completion) 기능을 사용할 수 있다. https:// 
github.com/git/git/blob/master/contrib/completion/git— completion. bash 에서 바로 다운 

받 는다. 그 파일을 홈 디텍 토리에 카 피하고 .bashrc 파일에 아래와 같은 내용을 추가 하자: 

source -/git-completion . bash 

또 모든사 용자가 사용할 수있게 설 정할수 있다. Mac 시스템 이라면 이 스크 립트를 /opt/local/etc/ 
bash.completion.d 디롁 토리에 복사 하고 리눅 스라면 /etc/bash— completion. d/ 에 복사 한다. 이 디텍토 

리는 Bash 가 자동 완성을 지 원하기 위해 사 용하는 디텍토 리다. 

윈도에 msysGit 을설 치해서 Git Bash 를사 용하는 경우에 는자동 완성이 미리 설 정되어 있다. 
Git 명렁을 입력할 때 <Tab〉 키를 누르면 Git 이 제 안하는 명 령어가 출력 된다: 

$ git co<tab><tab> 
commit config 



이 경우 git co 를입 력하고 Tab 키를 두번 누르면 commit 과 config 를 제안 한다. 이 때 m <tab>§ 입력 
하면 자 동으로 git commit 명령 을완성 한다. 

옵선 에도이 기능이 되고더 유용 하다. 예 를들어 git log 명령 을실행 하는데 옵션이 견혀 기 억나지 않 
는다면 아래와 같이 입 력하고 Tap 키를 누르면 아래와 같은 옵션을 제안 한다: 

$ git log — s<tab> 

―— shortstat — since= ―— src-pref ix= — stat ―— summary 
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2.7 절 팁 과트릭 



이건 상당히 멋진 팁 이다. 아 마문서 를찾아 보는등 의시간 을절약 해줄것 이다. 

2.7.2 Git Alias 

명령을 완 벽하게 입 력하지 않으면 Git 은 알 아듣지 못 한다. Git 의 명렁을 견부입 력하는 것이 귀 찮다면 
git conf ig 를 사 용하여 각 명령의 Alias 을 쉽게 만들 수 있다. 아래는 Alias 을 만드는 예 이다: 

$ git config —global alias. co checkout 

$ git config —global alias.br branch 

$ git config —global alias. ci commit 

$ git config —global alias. st status 



이제 git commit 대신 git ci 만 으로도 커밋할 수 있다. Git 을 계속 사용 한다면 다른 명 렁어도 자주 사용 
하게 될 것 이다. 자주 사 용하는 명렁은 Alias 을 만들어 편하게 사용 한다. 

이미 있 는명령 을편리 하고새 로운명 령으로 만들어 사 용할수 있다. 예 를들어 파일을 Unstage 상태 

로 변 경하는 명령을 만 들어서 불 편함을 덜 수 있다. 아래와 같이 unstage 라는 Alias 을 만 든다: 



$ git config —global alias. unstage 1 reset HEAD ―— 




아래 두명렁 은동일 한명령 이다: 

$ git unstage fileA 
$ git reset HEAD fileA 



한결 간결해 겼다. 추가로 last 명렁을 만들어 보자: 
$ git config —global alias. last 1 log -1 HEAD 1 



이제 최근 커밋을 좀 더 쉽게 확인할 수 있다: 

$ git last 

commit 66938dae3329c7aebe598c2246a8e6af90d04646 
Author: Gosh Goebel <dreamer3@example . com> 
Date: Tue Aug 26 19:48:51 2008 +0800 

test for current head 

Signed— off— by: Scott Chacon 〈schacon@example.com〉 
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이것으 로쉽게 새로운 명렁을 만들수 있다. 그리고 Git 의 명령어 뿐만아 니라외 부명령 어도실 행할수 
있다. ！를 제일 앞에 추 가하면 외부 명령을 실행 한다. 아래 명령은 git visual 이라고 입 력하면 gitk 가 
실행 된다: 



$ git config —global alias. visual 1 ！ gitk 



2.8 요약 

이제 우리는 로 컬에서 사용할 수 있는 Git 명령에 대한 기본 지식은 갖추 었다. 저 장소를 만들고 Clone 
하는 방법, 수 정하고 나서 Stage 하고 커 밋하는 방법， 저 장소의 히스 토리를 조 회하는 방법 등을 살펴보 
았다. 이 어지는 장 에서는 Git 의 가장 강력한 기능인 브랜치 모델을 살펴볼 것 이다. 
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모든버 전관리 시 스템은 브랜치 를지원 한다. 개 발을하 다보면 코드 를여러 개 로복사 해야하 는일이 
자주 생 긴다. 코드를 통째로 복 사하고 나서 원래 코 드와는 상 관없이 독립 적으로 개발을 진행할 수 있는 
데， 이렇게 독립 적으로 개 발하는 것이 브랜 치다. 

버견 관리 시스 렘에서 브 탠치를 만드는 과정은 고생스 립다. 개 발자가 수 동으로 소 스코드 디텍 토리를 
복 사해서 브 랜치를 만 들어야 하고 소스 코드의 양이 많으면 브 탠치를 만드는 시간도 오래 걸 린다. 

사 람들은 브랜치 모델이 Git 의 최고의 장점이 라고, Git 이 다른 것들과 구분되 는특깅 이라고 말 한다. 당 
최 어 떤점이 그렇게 특별한 것 일까? Git 의 브 탠치는 매우 가 볍다. 순 식간에 브 탠치를 새로 만들고 브 
탠치 사이를 이동할 수 있다. 다른 버전 관리 시스 템과는 달리 Git 은 브 랜치를 만들어 작 업하고 나중에 
Merge 하는 방법을 권장 한다. 심지어 하루에 수십 번 씩해도 괜 찮다. Git 브 랜치에 능숙 해지면 개발 방 
식이 완전히 바뀌고 다른 도구를 사용할 수 없게 된다. 

3.1 브랜치 란무엇 인가? 

Git 이 브탠 치하는 과정을 이해 하려면 우선 Git 이 데 이터를 어떻게 저장 하는지 알아야 한다. Git 은 데 

이터를 Change Set 이나 변 경사항 (Diff) 으로 기 록하지 않고 일련의 스냅 샷으로 기록 한다는 것을 1 장에 
서 보여 줬다. 

커 밋하면 Git 은 현 Staging Area 에 있는 데 이터의 스 냅샷에 대한 포 인터, 저자나 커밋 메시지 같은 메 
타데 이터, 이견 커밋에 대한 포인터 등을 포함하 는커밋 개체 (커밋 Object) 를저장 한다. 이전 커밋 포 
인터가 있어서 현재 커밋이 무엇을 기준 으 로 바뀌었 는지를 알 수 있다. 최초 커밋을 제외한 나머지 커밋 

은 이견 커밋포 인터가 격어도 하나씩 있고 브 탠치를 합친 Merge 커밋 같은 경 우에는 이견 커밋 포인터 
가 여러개 있다. 

예제를 보자. 파일이 3 개 있는 디텍 토리가 하나 있고 이 파일을 Staging Area 에 저 장하고 커밋해 
보자. 파일을 Stage 하면 Git 저 장소에 파일을 저 장하고 (Git 은 이것을 Blob 이라고 부 른다) Staging 
Area 에 해당 파일의 체크 심을저 장한다 (1 장에서 살펴본 SHA-1 을사 용한다 ). 

$ git add README test.rb LICENSE 

$ git commit -m ' initial commit of my project' 



'git commit' 으로 커 밋하면 먼저 루트 디롁 토리와 각 하위 디텍 토리의 트리 개체를 체 크심과 함께 저 
장소에 저장 한다. 그 다음에 커밋 개체를 만들고 메타데 이터와 루트 디 텍토리 트리 개체를 가 리키는 포 
인터 정보를 커밋 개체에 넣어 저장 한다. 그래서 필 요하면 언 제든지 스 냅샷을 다시 만들 수 있다. 
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이 작업을 마치고 나면 Git 저장 소에는 다섯 개의 데이터 개 체가생 긴다. 각 파일에 대한 Blob 세 개， 파 
일과디 텍토리 구조 가들어 있 는트리 개체 하나， 메타데 이터와 루트트 리를가 리키는 포인터 가담긴 커 
밋개체 하나 이다. 이것을 그림으 로그리 면그림 3-1 과 같다. 



commit 


size 


tree 


92AC2 


author 


Scott 


committer 


Scott 







Mob Sbld3 README 

Mob 9iie7 Ilzcbhss 



cbaOa test.: 



blob 


size 


― TtMlnf Llkrary 
Thlt likfwy It M*4 


tO tMt 


911o7. . 


blob 


size 


Jh» MT Lltanw 




(a^fXft <c) 예 r ，ᅵ "epy'tgnt 
^•r«U"an 1， grM«i, 



cbaOa. ■ 



blob 



그림 3.1: 저장소 의커밋 데이터 



다시 파일 을수정 하고커 밋하면 이견 커밋이 무 엇인지 도저장 한다. 커밋 을두번 더 하면 그림 3-2 과 
같이 저장 된다. 
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그림 3.2: Git 커밋 의개체 데이터 



Git 의 브 탠치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것 이다. 기본 적으로 Git 은 master 

브 랜치를 만 든다. 최초로 커 밋하면 Git 은 master 라는 이름의 브 랜치를 만 들어서 자 동으로 가장 마지 
막커 밋을가 리키게 한다. 



master 
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그림 3.3: 가장 최근 커밋 정보를 가 리키는 브랜치 



브 탠치를 하나 새로 만들면 어 떨까? 브 탠치를 하나 만 들어서 놀자. 다음과 같이 git branch 명 렁으로 
testing 브 랜치를 만 든다. 
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3.1 절 브탠치 란무엇 인가? 



$ git branch testing 



새로 만든 브 탠치도 지금 작 업하고 있던 마지막 커밋을 가 리킨다 (그림 3-4). 



98ca9 
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그림 3.4: 커밋 개체 를가리 키는두 브랜치 



지금 작업 중인 브 탠치가 무 엇인지 Git 은 어떻게 파약 할까? 다른 버전 관리 시스 템과는 달리 Git 은 
'HEAD' 라는 특수한 포 인터가 있다. 이 포 인터는 지금 작 업하는 로걸 브 탠치를 가리 킨다. 브 탠치를 새 
로 만들었 지만， Git 은아직 master 브탠 치를가 리키고 있다. git branch 명렁은 브랜치 를만들 기만하 
고브랜 치를옮 기지않 는다. 
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그림 3.5: HEAD 는 현재 작업 중인 브 랜치를 가리김 

git checkout 명 령으로 새로 만든 브 탠치로 이동할 수 있다. testing 브 탠치로 이동 하려면 다음과 같이 
한다: 



$ git checkout testing 



이렇게 하면 HEAD 는 testing 브 탠치를 가리 킨다. 
자, 이제 핵심이 보일 거다! 커밋을 새로한 번 해 보면: 



$ vim test .rb 

$ git commit —a -m 'made a change 1 
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그림 3.6: HEAD 는옮 겨간다 른브랜 치를가 리킨다 
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그림 3.7: HEAD 가가 리키는 testing 브랜 치가새 커 밋을가 리킨다 

결과 는그림 3-7 과 같다. 

이 부분이 흥미 롭다. 새로 커 밋해서 testing 브 탠치는 앞으로 이동 했다. 하 지만， master 브 탠치는 여전 
히 이견 커밋 을가리 킨다. master 브 탠치로 되돌아 가면: 



$ git checkout master 



결과 는그림 3—8 과 같다. 
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그림 3.8: HEAD 가 Checkout 한브 랜치로 이동함 



방금 실행한 명렁이 한 일은 두 가 지다. master 브 랜치가 가 리키는 커밋을 HEAD 가 가 리키게 하고 워 
킹 디텍 토리의 파일도 그 시 점으로 되돌려 놓 았다. 앞으로 커밋을 하면 다른 브 랜치의 작 업들과 별개로 
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3.2 절 브 탠치와 Merge 의 기초 



진 행되기 때문에 testing 브탠 치에서 임시로 작업하 고원래 master 브랜 치로돌 아와서 하던 일 을계속 
할수 있다. 

파일을 수 정하고 다시 커밋을 해 보자: 



$ vim test .rb 

$ git commit —a -m 'made other changes 1 



프로젝 트히스 토리는 분리돼 진 행한다 (그림 3-9). 우리는 브랜치 를하나 만들어 그브탠 치에서 일을 

좀 하고， 다시 원래 브 탠치로 되돌 아와서 다른 일을 했다. 두 작업 내용은 서로 독립 격으로 각 브랜치 

에 존재 한다. 커밋 사이를 자 유롭게 이동 하다가 때가 되면 두 브 탠치를 Merge 한다. 간단히 branch 와 

checkout 명령을 써서말 이다. 
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그림 3.9: 브랜치 히스 토리가 서로독 립적임 

실제로 Git 의 브 탠치는 어떤 한 커밋을 가 리키는 40 글자의 SHA-1 체크심 파일에 불 과하기 때문에 만 
들기도 쉽고 지 우기도 쉽다. 새로 브 탠치를 하나 만드는 것은 41 바이트 크기의 파일을 (40 자와 줄바꿈 
문자) 하나만 드는것 에불과 하다. 

브 랜치를 만 들어야 하면 프로 젝트를 통째로 복사해 야하는 다튼 버전 관리 도구와 Git 의 차이는 극명하 
다. 통째로 복 사하는 작업은 프 로젝트 크기에 따라 다르 겠지만 수십 초에서 수십 분까지 걸 린다. 그에 
비해 Git 은 순식간 이다. 게다가 커밋을 할때마 다이전 커밋의 정 보를저 장하기 때문에 Merge 할때어 
디 서부터 (Merge Base) 합처야 하는지 안다. 이런 특징은 개발 자들이 수시로 브 랜치를 만들어 사용하 
게 한다. 

이제 왜 그렇게 브 랜치를 수시로 만들고 사 용해야 하는지 알아 보자. 



3.2 브 랜치와 Merge 의기초 

실제 개발과 정에서 겪을 만한 예제를 하나 살펴 보자. 브 랜치와 Merge 는 보통 이런 식으로 진행 한다: 

1. 작업중 인웹사 이트가 있다. 

2. 새 로운이 슈를처 리할새 Branch 를하나 생성. 

3. 새로 만든 Branch 에서 작업 중. 
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이때 중요한 문제가 생겨서 그것을 해 결하는 Hotfix 를 먼저 만 들어야 한다. 그러면 다음과 같이 할 수 
있다: 

1. 새 로운이 슈를처 리하기 이견의 운영 (Production) 브 랜치로 이동. 

2. Hotfix 브탠 치를새 로하나 생성. 

3. 수정한 Hotfix 테 스트를 마치고 운영 브 랜치로 Merge. 

4. 다시 작 업하던 브 랜치로 옮 겨가서 하던 일 진행. 

3.2.1 브탠치 의기초 

먼저커 밋을몇 번했다 고가정 하자. 



그림 3.10: 현재 커밋히 스토리 

이슈 관리 시 스템에 등록된 53 번 이슈를 처리 한다고 하면 이 이슈에 집중할 수 있는 브 탠치를 새로 하 
나 만 든다. Git 은 어떤 이슈 관리 시스 템에도 종속돼 있지 않다. 브 탠치를 만 들면서 Checkout 까지 한 
번에 하려면 git checkout 명령에 -b 라는 옵션을 준다. 

$ git checkout -b iss53 
Switched to a new branch ' iss53' 

위 명령은 아래 명렁을 줄 여놓은 것 이다: 

$ git branch iss53 
$ git checkout iss53 

그림 3-1 1 은위 명령의 결과를 나타 낸다. 





그림 3.1 1 ： 브랜치 포 인터를 새로 만듦 

iss53 브 랜치를 Checkout 했기 때문에 (즉， HEAD 는 iss53 브랜치 를가리 킨다) 뭔가 일을하 고커밋 
하면 iss53 브 랜치가 앞으로 진행 한다: 
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$ vim index.html 

$ git commit -a -m 1 added a new footer [issue 53] 



， 




그림 3.1 2: 진행 중인 iss53 브랜치 

다른 상황을 가정해 보자. 만드는 사 이트에 문제가 생겨서 즉시 고처야 한다. 버그를 해결한 Hotfix 에 
'iss53' 이 섞이는 것을 방 지하기 위해 'iss53' 와 관련된 코 드를어 딘가에 저장 해두고 원래 운영 환경의 
소 스로복 구해야 한다. Git 을사 용하면 이런 노력 을들일 필요 없이 그낭 master 브 탠치로 옮기면 된다. 
그렇 지만, 브 탠치를 이동 하려면 해야 할 일이 있다. 아직 커 밋하지 않은 파일이 Checkout 할 브 랜치와 
충돌나 면브탠 치를변 경할수 없다. 브탠치 를변경 할때에 는워킹 디랙 토리를 정리하 는것이 좋다. 이 
런 문제를 다루는 방법은 (주 로， Stash 이나 커밋 Amend 에 대해) 나중에 다룰 것 이다. 지금은 작업하 
던 것을 모두 커 밋하고 master 브 랜치로 옮 긴다: 

$ git checkout master 
Switched to branch 'master' 

이 때워킹 디텍 토리는 5 3 번 이 슈를시 작하기 이견 모습으 로되돌 려지기 때문 에새로 운문제 에집중 
할 수 있는 환경이 만들어 진다. Git 은 자 동으로 워킹 디텍 토리에 파 일들을 추가 하고, 지 우고, 수 정해서 
Checkout 한 브 랜치의 스냅 샷으로 되돌려 놓 는다는 것을 기 억해야 한다. 
hotfix 라는 브 랜치를 만들고 새로운 이슈를 해결할 때까지 사용 한다: 

$ git checkout -b hotfix 
Switched to a new branch 1 hotfix 1 
$ vim index.html 

$ git commit —a -m 1 fixed the broken email address 1 
[hotfix 3a0874c] fixed the broken email address 
1 files changed, 1 deletion(-) 

운영 환경에 적용 하려면 문 제를제 대로고 쳤는지 테스 트하고 master 브 랜치에 합처야 한다. git merge 
명 렁으로 다음 과같이 한다: 



$ git checkout master 
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master I hotfix 



스 S 



C3 



그림 3.13: master 브랜 치에서 갈라져 나온 hotfix 브랜치 



$ git merge hotfix 
Updating f 42c576 . . 3a0874c 
Fast-forward 
README ！ 1 - 

1 file changed, 1 deletion(-) 



Merge 메시 지에서 'Fast-forward' 가보이 는가? Merge 할브 탠치가 가리키 고있던 커밋이 현브랜 
치가가 리키는 것보다 '앞 으로진 행한' 커 밋이기 때문에 master 브랜치 포인터 는최신 커밋으 로이동 
한다. 이런 Merge 방식을 'Fast forward' 라고 부 른다. 다시 말해서 A 브랜 치에서 다른 B 브 탠치를 
Merge 할때 B 가 A 이후의 커 밋을가 리키고 있으면 그저 A 가 B 의 커 밋을가 리키게 할뿐 이다. 
이제 hotfix 는 master 브 랜치에 포 함됐고 운영 환경에 적용할 수 있다 (그림 3-14). 




그림 3.14: Merge 후 hotfix 브랜치 와같은 것을가 리키는 master 브랜치 



문제 를급히 해 결하고 master 브 랜치에 적 용하고 나면 다시 일하던 브탠 치로돌 아가야 한다. 하 지만， 

그견에 필 요없는 hotfix 브 랜치를 삭제 한다. git branch 명령에 -d 옵션을 주고 브 랜치를 삭제 한다. 



$ git branch — d hotfix 

Deleted branch hotfix (was 3a0874c ) . 



자 이제 이슈 53 번을 처 리하던 환 경으로 되돌 아가서 하던 일을 계속 하자 (그림 3-15): 
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$ git checkout iss53 
Switched to branch ' iss53' 
$ vim index.html 

$ git commit —a -m ' finished the new footer [issue 53] 
[iss53 ad82d7a] finished the new footer [issue 53] 
1 file changed, 1 insertion(+) 




그림 3.1 5： master 와 별개로 진 행하는 iss53 브랜치 



위에서 작업한 hotfix 가 iss53 브 랜치에 영향을 끼치지 않 는다는 점을 이 해하는 것이 중요 하다. git 
merge master 명 령으로 master 브 탠치를 iss53 브 랜치에 Merge 하면 iss53 브 탠치에 hotfix 가 격용 
된다. 아니면 j SS 53 브 랜치가 master 에 Merge 할 수있는 수준이 될 때까지 기다 렸다가 Merge 하면 
hotfix 와 iss53 가합처 진다. 

3.2.2 Merge 의 기초 

53 번 이슈 를다구 현하고 master 브 랜치에 Merge 하 는과정 을살펴 보자. master 브 랜치에 Merge 

하는 것은 앞서 살펴본 hotfix 브 랜치를 Merge 하는 것 과비숫 하다. git merge 명 령으로 합칠 브 랜치에 

서 합처질 브 탠치를 Merge 하면 된다: 

$ git checkout master 
$ git merge iss53 
Aut 으 merging README 

Merge made by the 'recursive' strategy. 
README ！ 1 + 

1 file changed, 1 insertion(+) 

hotfix 를 Merge 했을 때와 메 시지가 다 르다. 현 브탠 치가가 리키는 커밋이 Merge 할 브 랜치의 조상이 
아 니으로 Git 은' Fast-forward' 로 Merge 하지 않 는다. 이러면 Git 은 각 브 랜치가 가 리키는 커밋 두 개 
와공통 조상하 나를사 용하여 3-way Merge 를 한다. 그림 3—1 6 에 이 Merge 에서 사 용하는 커밋세 
개 가표시 된다. 

단순히 브탠치 포 인터를 최신 커 밋으로 옮기는 게 아니라 3-way Merge 의 결과를 별도의 커 밋으로 
만들 고나서 해당 브랜치 가그커 밋을가 리키도 록이동 시킨다 (그림 3-17). 그래서 이런 커밋은 부모가 
여러 개고 Merge 커밋 이라고 부 른다. 
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그림 3.1 6: Git 은 Merge 에 필요한 공통 커밋을 자 동으로 찾음 

Git 은 Merge 하는데 필요한 최적의 공통 조상을 자 동으로 찾 는다. 이런 기능도 Git 이 다튼 버견 관리 
시스 템보다 나은 점 이다. CVS 나 Subversion 같은 버전 관리 시 스템은 개 발차가 직접 공통 조상을 찾 
아서 Merge 해야 한다. Git 은 다 른시스 템보다 Merge 가 대단히 쉽다. 



(3 



그림 3.1 7: Git 은 Merge 할 때 Merge 에 대한 정보가 들어 있는 커밋를 하나 만 든다. 




iss53 브 랜치를 master 에 Merge 하고 나면 더는 iss53 브랜치 가필요 없다. 다음 명 령으로 브 랜치』 
삭 제하고 이슈의 상태를 처리 완료로 표시 한다: 



$ git branch ᅳ d iss53 



3.2.3 충돌 의기초 

가끔씩 3-way Merge 가 실패할 때도 있다. Merge 하는 두 브탠 치에서 같은 파일의 한 부분을 동시에 
수 정하고 Merge 하면 Git 은 해당 부분을 Merge 하지 못 한다. 예를 들어, 53 번 이슈와 hotfix 가 같은 
부분을 수정 했다면 Git 은 Merge 하지 못하고 다음과 같은 충돌 (Conflict) 메 시지를 출력 한다: 



$ git merge iss53 
Auto-merging index. html 
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CONFLICT (content) ： Merge conflict in index. html 

Automatic merge failed; fix conflicts and then commit the result. 

Git 은자 동으로 Merge 하지 못해서 새 커밋이 생기지 않 는다. 변경 사항의 충돌 을개발 자가해 결하지 
않는 한 Merge 과정을 진행할 수 없다. Merge 충돌이 일 어났을 때 Git 이 어떤 파일을 Merge 할 수 없 
었는 지살펴 보려면 git status 명렁 을이용 한다: 

$ git status 

On branch master 

You have unmerged paths. 

(fix conflicts and run "git commit" ) 

Unmerged paths: 
(use "git add <file>. . . " to mark resolution) 

both modified: index.html 

no changes added to commit (use "git add" and/or "git commit —a") 



충돌이 일어난 파일은 unmerged 상태 로표시 된다. Git 은 충돌이 난부분 을표준 형식에 따라 표시해 
준다. 그러면 개발자 는해당 부분을 수동으 로해결 한다. 충 돌난부 분은다 음과같 이표시 된다. 



HEAD 

<div id=' footer ">contact ： email.s 니 pport@gith 니 b.com〈/div〉 



<div id='footer'> 

please contact us at support@github.com 
</div> 

iss53 



_= 위쪽의 내용은 HEAD 버전 (merge 명렁을 실행할 때 작 업하던 master 브 탠치) 의 내 용이고 
아 래쪽은 iss53 브 탠치의 내용 이다. 충돌을 해결 하려면 위 쪽이나 아래쪽 내용 중에서 고 르거나 새로 작 
성하여 Merge 한다. 다음 은아예 새로작 성하여 충돌을 해결하 는예제 다: 



<div id=' footer 1 ) 

please contact us at email . support@github . com 
</div> 

충돌한 양 쪽에서 조금씩 가 겨와서 새로 수정 했다. 그리고 〈〈<〈«〈， ===， »»»> 가 포함된 행을 삭 
제하 였다. 이렇게 충 돌한부 분을해 결하고 git add 명 렁으로 다시 Git 에 저장 한다. 충돌을 쉽게 해결하 
기 위해 다른 Merge 도구도 이용할 수 있다. git mergetool 명 렁으로 실행 한다: 
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$ git mergetool 

This message is displayed because 'merge. tool 1 is not configured. 

See 'git mergetool ―— tool-help' or 'git help config 1 for more details. 

■git mergetool 1 will now attempt to use one of the following tools: 

opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis be 3 codecompare vimdiff 

Merging: 

index.html 

Normal merge conflict for 'index.html' ： 

{local} ： modified file 

{remote} ： modified file 
Hit return to start merge resol 니 tion tool (opendiff) ： 

Mac 에서는 opendiff 가실행 된다. 기본 도구말 고사용 할수있 는다른 Merge 도 구도있 는데， "… one 
of the following tools:" 부분에 보여 준다. 여기에 표시된 도구 중 하나를 고를 수 있다. Merge 도구 
를 변 경하는 방법은 7 장에서 다 툰다. 

Merge 도구를 종 료하면 Git 은 잘 Merge 했는지 물어 본다. 잘 마 쳤다고 입 력하면 자 동으로 git add 가 

수행되 고해당 파일이 Staging Area 에 저장 된다. 

git status 명 렁으로 충돌이 해결된 상 태인지 다시 한번 확 인해볼 수 있다. 

$ git status 
On branch master 
Changes to be committed: 

(use 'git reset HEAD <f ile>. . . 1 to unstage) 

modified: index.html 

충돌을 해 결하고 나서 해당 파일이 Staging Area 에 저장 됐는지 확인 했으면 git commit 명 렁으로 
Merge 한 것을 커밋 한다. 충돌을 해 결하고 Merge 할 때에는 커밋 메 시지가 아래와 같다. 

Merge branch 1 iss53' 

Conflicts: 
index.html 

# 

# It looks like you may be committing a merge . 

# If this is not correct, please remove the file 

# .git/MERGE_HEAD 

# and try again. 
# 
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3.3 절 브탠치 관리 



어떻게 충돌을 해 결했고 좀 더 확 인해야 하는 부분은 무엇을 어떻게 했는지 자세 하게 기록 한다. 자세한 
기록은 나중에 이 Merge 커밋을 이해 하는데 도움 을줄것 이다. 

3.3 브랜 치관리 

지 금까지 브 탠치를 만 들고, Merge 하고， 삭 제하는 방법에 대해서 살펴왔 다. 브 랜치를 관 리하는 데 필 
요한다 른명령 도살펴 보자. 

git branch 명령은 단순히 브 탠치를 만들고 삭제해 주기만 하는 것이 아 니다. 아무런 옵션 없이 실행하 
면 브탠치 의목록 을보여 준다: 

$ git branch 

iss53 
* master 

testing 



* 기호가 붙어 있는 master 브 랜치는 현개 Checkout 해서 작 업하는 브 탠치를 나타 낸다. 즉, 지금 수정 

한내 용을커 밋하면 master 브 랜치에 커밋 되고포 인터가 앞으로 한단게 나아 간다. git branch -v 명 

렁을실 행하면 브 탠치마 다마지 막커밋 메시지 도함께 보여 준다: 



$ git branch -v 




iss53 93b412c fix javascript issue 




★ master 7a98805 Merge branch 1 iss53' 




testing 782fd34 add scott to the author list i 


n the readmes 



각 브 랜치가 지 금어떤 상 태인지 확인 하기에 좋은 옵션도 있다. 현재 Checkout 한 브 탠치를 기 준으로 

Merge 된 브탠 치인지 그렇지 않은지 필 터링해 볼 수 있다. -merged 와 -no-merged 옵션을 사 용하여 해 
당목록 을볼수 있다. git branch -merged 명렁으 로이미 Merge 한 브탠치 목록 을확인 한다: 



$ git branch —merged 

iss53 
* master 



iss53 브 랜치는 앞에서 이미 Merge 했기 때문에 목록에 나타 난다. * 기호 가붙어 있지 않은브 랜치는 
git branch -d 명령으 로삭제 해도되 는브탠 치다. 이미 다른브 랜치와 Merge 했기 때 문에삭 제해도 ; 정 

보를 잃지않 는다. 

반대 로현재 Checkout 한브 탠치에 Merge 하지 않은 브탠치 를살펴 보려면 git branch -no-merged 명 
렁 을사용 한다: 



$ git branch —no-merged 
testing 
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위에는 없었던 다른 브 탠치가 보 인다. 아직 Merge 하지 않은 커밋을 담고 있기 때문에 git branch -d 
명령으 로삭제 되지않 는다: 



$ git branch — d testing 

error: The branch 'testing' is not fully merged . 

If you are sure you want to delete it, run 'git branch — D testing' . 



Merge 하지 않은 브 랜치를 강제로 삭제 하려면 -D 옵 션으로 삭제 한다. 



3.4 브랜치 Workflow 



브 탠치를 만들고 Merge 하는 것을 어디에 써 먹어야 할까? 이 결 에서는 Git 의 브 랜치가 유용한 몇 가 
지 Workflow 를살펴 본다. 여기서 설 명하는 Workflow 를 개발에 격 용하면 도움이 될 것 이다. 



3.4.1 Long-Running 브랜치 

Git 은 꼼 꼼하게 3-way Merge 를 사 용하기 때문에 장 기간에 걸처서 한 브 탠치를 다른 브 탠치와 여러 
번 Merge 하는 것도 어렵지 않다. 그래서 개발 과 정에서 필요한 용도에 따라 브 탠치를 만들어 두고 계 
속 사용할 수 있다. 그리고 정기 적으로 브 랜치를 다른 브 랜치로 Merge 한다: 
이런 집 근법에 따라서 Git 개 발자가 많이 선 호하는 Workflow 가 하나 있다. 배포 했거나 배포할 코드만 
master 브 랜치에 Merge 해서 안정 버견의 코드만 master 브 탠치에 둔다. 개발을 진 행하고 안 정화하 
는 브 랜치는 develop 이나 next 라는 이 름으로 추가로 만들어 사용 한다. 이 브 랜치는 언젠가 안정 상태 
가 되겠 지만, 항상 안정 상태를 유 지해야 하는 것이 아 니다. 테 스트를 거처서 안정적 이라고 판 단되면 
master 브 탠치에 Merge 한다. 토픽 브탠치 (앞서 살펴본 iss53 브랜치 같은 짧은 호흡 브 탠치) 에도 적 
용할 수 있 는데， 해당 토픽을 처 리하고 테스 트해서 버그도 없고 안정 격이면 그때 Merge 한다. 
사실 우리가 얘 기하는 것은 커밋을 가 리키는 포 인터에 대한 애 기다. 개발 브 탠치는 공격 격으로 히스토 
리를 만들어 나 아가고 안정 브랜치 는이미 만든 히스 토리를 뒤 따르며 나아 간다. 





C2 j<— ^ C3 ^ C4 ) ■« ᅳ ^ C5 j-*-^ C6 j« 

그림 3.18: 안정적 인브랜 치일수 록커밋 히스토 리가뒤 처진다 



실험 실에서 충분히 테스 트하고 실전에 배 치하는 과정으 로보면 이 해하기 쉽다 (그림 3-19). 
코드 를여러 단계로 나누어 안 정성을 높 여가며 운영할 수 있다. 큰 규모의 프로젝 트라면 proposed 혹 
은 pu(proposed updates) 라는 이름의 브 탠치를 두어 next 나 master 브 탠치에 아직 Merge 할 준 
비 가되지 않은것 을일단 Merge 시 킨다. 

중 요한개 념은브 탠치를 이용해 여러 단계에 걸처서 안 정화해 나아 가면서 충분히 안 정화가 됐을때 안 
정 브 탠치로 Merge 한 다는점 이다. 다시 말해서 반드시 Long-Running 의 브랜치 를여러 개 만 들어야 
하는 것은 아 니지만 정말 유용 하다. 특히 규모가 크고 복잡한 프 로젝트 일수록 그 유 용성이 반 짝반짝 빛 
난다. 
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master 



develop 



topic 




그림 3.1 9: 각 브 랜치를 하나의 실 험실로 생 각하라 

3.4.2 토픽 브탠치 

토픽 브 탠치는 프 로젝트 크기에 상 관없이 유용 하다. 토픽 브 탠치는 어떤 한 가지 주제나 작업을 위해 만 
든짧은 호흡의 브탠 치다. 다른 버견 관리 시스 템에서 이런 브 랜치를 본격이 없을 것 이다. Git 이 아닌 
다른 버견 관리 도구 에서는 브 탠치를 하나 만드는 데 큰 비용이 든다. Git 에서는 매우 일상 적으로 브랜 
치를 만들고 Merge 하고 삭제 한다. 

앞서 사용한 iss53 이나 hotfix 브 탠치가 토픽 브랜 치다. 우리는 브 랜치를 새로 만들고 어느 정도 커밋 
하고 나서 다시 master 브 랜치에 Merge 하고 브랜치 삭제도 해 보 았다. 보통 주 제별로 브 탠치를 만들 
고 각각은 독립돼 있기 때문에 매우 쉽게 컨 텍스트 사이를 옮겨 다닐 수 있다. 묶 음별로 나눠서 일하면 
내 용별로 검 토하기 에도， 테 스트하 기에도 더 편 하다. 각 작업을 하루든 한 달이든 유지 하다가 master 
브 탠치에 Merge 할 시점이 되면 순서에 관 계없이 그때 Merge 하면 된다. 
master 브 랜치를 checkout 한 상 태에서 어떤 작업을 한다고 해 보자. 한 이슈를 처 리하기 위해서 
iss91 라는 브 탠치를 만들고 해당 작업을 한다. 같은 이슈를 다른 방 법으로 해결 해보고 싶을 때도 있다. 
iss91 v2 라는 브 탠치를 만들고 다른 방법을 시도해 본다. 확신할 수 없는 아이 디어를 격용 해보기 위해 
다시 master 브랜치 로되돌 아가서 dumbidea 브탠치 를하나 더 만 든다. 지 금까지 말했던 커밋 히스 
토리 는그림 3-20 과 같다. 




그림 3.20: 여러 토픽 브 랜치에 대한 커밋 히 스토리 



이슈를 처 리했던 방법 중 두번째 방법인 iss91 v2 브 랜치가 괜 찮아서 적용 하기로 결정을 내 렀다. 그리 
고 아이 디어를 확 신할수 없었던 dumbidea 브 탠치를 같이 일하는 다른 개발 자에게 보여 줬더니 썩 괜 
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찮다는 반응을 얻 었다. iss91 브 랜치는 (C5， C6 커밋도 함께) 버리고 다른 두 브 랜치를 Merge 하면 그 
림 3-21 과같이 된다. 




그림 3.21 ： dumbidea 와 iss91 v2 브 랜치를 Merge 하고 난 후의 모습 

지 금까지 한 작업은 견부 로컬 에서만 처리 한다는 것을 꼭 기억 하자. 로컬 저장소 에서만 브 랜치를 만들 
고 Merge 했으며 서버와 통신을 주 고받는 일은 없 었다. 

3.5 리모트 브랜치 

리모트 브 랜치란 리모트 저 장소에 있는 브 탠치를 말 한다. 사실 리모트 브 탠치도 로컬에 있지만 멋대로 
옮 기거나 할 수 없고 리모트 저 장소와 통 신하면 자 동으로 업 데이트 된다. 리모트 브 탠치는 브탠치 상태 
를 알 려주는 책갈 피라고 볼 수 있다. 이 책 갈피로 리모트 저장 소에서 마지 막으로 데 이터를 가겨온 시점 
의상태 를알수 있다. 

리 모트브 탠치의 이름은 (remote) /(branch) 형식으 로되어 있다. 예 를들어 리모트 저장소 origin 의 
master 브 탠치를 보고 싶다면 origin/master 라는 이 름으로 브 랜치를 확 인하면 된다. 다른 팀원과 함 
께 어떤 이 슈를구 현할때 그 팀원이 iss53 브 탠치를 서버로 Push 했고 당신도 로걸에 iss53 브 랜치가 
있다 고가정 하자. 이때서 버가가 리키는 iss53 브랜 치는로 컬에서 origin/iss53 이 가리키 는커밋 이다. 

다소 헷갈릴 수 있으니 예제 를좀더 살펴 보자. git. ourcompany.com 이라는 Git 서버가 있고 이 서버의 

겨 장소를 하나 Clone 하면 Git 은 자 동으로 origin 이라는 이름을 붙 인다. origin 으 로부터 저장소 데이 
터를 모두 내 려받고 master 브 랜치를 가 리키는 포 인터를 만 든다. 이 포 인터는 origin/master 라고 부 
르고 멋대로 조종할 수 없다. 그리고 Git 은 로걸의 master 브 탠치가 origin/master 를 가 리키게 한다. 
이제 이 master 브탠 치에서 작업을 시작할 수 있다. 

로컬 저캉 소에서 어떤 작업 을하고 있는데 동시에 다른 팀원이 git.ourcompany.com 서버에 Push 하고 

master 브 랜치를 업 데이트 한다. 그러면 이제 팀원 간의 히 스토리 는서로 달라 진다. 서버 저장 소로부 
터 어떤 데이 터도주 고받지 않아서 origin/master 포인터 는그대 로다. 

리모 트서버 로부터 저장소 정보를 동기화 하려면 git fetch origin 명령 을사용 한다. 명렁을 실행하 
면 우선 origin 서버의 주 소정보 (이 예 에서는 git. ourcompany.com) 를찾 아서， 현재 로컬의 겨장 소가갖 
고 있지 않은 새로운 정보가 있으면 모두 내려 받고， 받은 데 이터를 로컬 저 장소에 업데이 트하고 나서, 
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git.ourcompany.com 



master 




^ git clone schacon^git . ourcompany . com: pro ject . git 



My Computer 


1 origin/master 

1 

( 0b743 ^ 째ᅳ ( a6b4c £42c5 ^ 

master 


Remote Branch 




m …… Local Branch 



그림 3.22: 저 장소를 Clone 하면 로컬 master 브 랜치， 리모트 저 장소의 master 브 탠치를 가 리키는 
origin/master 브 랜치가 생김 



gitourcompany.com 



( 0b743 »6b4c "2<:1"누*~^ 31b" ^"l90a3 ) -" 



Someone else pushes 



My Computer 




그림 3.23: 로컬과 서버의 커밋 히스토 리는독 립적임 



origin/master 포 인터의 위치 를최신 커 밋으로 이동시 킨다. 

리모트 저장소 를여러 개 운 영하는 상황을 이해할 수 있도록 개발 용으로 사용할 Git 저 장소를 팀 내부 
에 하나 추가해 보자. 

이 겨 장소의 주소가 git. tear! .ourcompany. com 이면 2 장에서 살펴본 git remote add 명 령으로 현재 작 

업 중인 프로 젝트에 팀의 저 장소를 추가 한다. 이름을 teamone 으로 칫고 긴 서버 주소 대신 사용 한다. 

서버를 추 가하고 나면 git fetch teamone 명 렁으로 teamone 서버의 데 이터를 내려받 는다. 명렁을 
실 행해도 teamone 서버의 데이터 는모두 origin 서버에 도있는 것들 이라서 아무 것도내 려받지 않는 
다. 하 지만, 이 명령은 teamone/master 브 랜치가 teamone 서버의 master 브탠치 가가리 키는커 
밋을가 리키게 한다. 
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git.ourcompany.com 



( 0b743 a6b4c) 북-신 f42c5 31b8e ^"l90a3 ) 



git fetch origin 



My Computer 



( 0b743 ) 째— ( a6b4c ^f42c5 31b8e 》~( 190a3 ) 




그림 3.24: Git 의 Fetch 명령은 리모트 브랜치 정보를 업데이 트한다 



git.ourcompany.com 



gitteaml .ourcompany.com 



git remote add taaaont gi t : / /gi t . teaml . ourcompany . coa 



My Computer 






ortgln /(natter 






( Qb743 ^■*-^«6b4c < "2c5 ^ 3lb8m ^ 190«3j 


( a3Bde ^ 693cg ) 








nusier 



그림 3.25: 서버를 리모트 저 장소로 추 가하기 



3.5.1 Push 하기 



로컬의 브 탠치를 서버로 전송 하려면 쓰기 권한이 있는 리모트 저 장소에 Push 해야 한다. 로걸 저장소 
의 브 랜치는 자 동으로 리모트 저 장소로 견 송되지 않 는다. 명시 격으로 브 탠치를 Push 해야 정보가 견송 
된다. 따라서 리모트 저 장소에 견 송하지 않고 로컬 브탠 치에만 두는 비공개 브 탠치를 만들 수 있다. 또 

다튼 사람과 협 업하기 위해 토픽 브 탠치만 전송할 수도 있다. 

serverfix 라는 브 랜치를 다른 사람과 공유할 때에도 브 랜치를 처음 Push 하는 것과 같은 방 법으로 

Push 한다. 다음 과갈이 git push (remote) (branch) 명령 을사용 한다: 



$ git push origin serverfix 
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oflgtn/ master 




( 0b743 y*~^6t>4c "2c5 ^ 


31b8« J-< —— ( 190a3 ) 
( a3flde ( 893ef j 

t 











그림 3.26: 로걸 저 장소에 만 들어진 teamone 의 master 브 랜치를 가 리키는 포인터 



Counting objects: 20, done. 
Compressing objects: 100% (14/14), done. 
Writing objects: 100% (15/15), 1.74 KiB, done. 
Total 15 (delta 5), reused 0 (delta 0) 
To git@github . com: schacon/ simplegit.git 
* [new branch] serverf ix -> serverf ix 



이메시 지에는 숨겨진 내용이 많다. 

Git 은 serverfix 라는 브탠치 이름을 refs/heads/serverf ix:refs/heads/serverf ix 로 확장 한다. 이것은 

serverfix 라는 로걸 브 랜치를 서버로 Push 하는데 리 모트의 serverfix 브 탠치로 업 데이트 한다는 것 

을의미 한다. 나중에 9 장에서 refs/heads/ 의뜻을 자세히 알아볼 것이기 때문에 일 단님어 가도록 한다. 
git push origin serverfix:serverfix 라고 Push 하는 것도같 은의미 인데이 것은' 로걸의 serverfix 브 

탠치를 리모트 저 장소의 serverfix 브 랜치로 Push 하라' 라는 뜻 이다. 로컬 브 랜치의 이름과 리모트 서 
버의 브탠치 이름이 다를 때 필요 하다. 리모트 저 장소에 serverfix 라는 이름 대신 다른 이름을 사용하 

려면 git push origin serverfix :awesomebranch 처럼사 용한 다. 

나중에 누군가 저 장소를 Fetch 하고 나서 서버에 있는 serverfix 브 탠치에 접근할 때 origin/serverfix 
라 는이름 으로집 근할수 있다: 



$ git fetch origin 
remote: Counting objects: 20, done, 
remote: Compressing objects: 100% (14/14), done, 
remote: Total 15 (delta 5), reused 0 (delta 0) 
Unpacking objects: 100% (15/15), done. 
From git@github. com: schacon/simplegit 
* [new branch] serverfix -> origin/serverfix 



여기서 겊고 님 어가야 할 게 있다. Fetch 명 령으로 리모트 브 탠치를 내려받 는다고 해서 로컬 저 장소에 
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수정 할수있 는브랜 치가새 로생기 는것이 아 니다. 다시 말해서 serverfix 라는 브랜치 가생기 는것이 
아니라 그저 수정 못 하는 origin/serverfix 브랜치 포 인터가 생기는 것 이다. 

새로 받은브 탠치의 내용을 Merge 하려면 git merge origin/serverfix 명령 을사용 한다. Merge 하지 
않고 리모트 브탠 치에서 시 작하는 새 브 탠치를 만 들려면 아래와 같은 명령을 사용 한다. 

$ git checkout — b serverf ix origin/serverfix 

Branch serverf ix set up to track remote branch serverf ix from origin. 
Switched to a new branch ' serverf ix' 

그러면 origin/serverfix 에서 시 작하고 수정할 수 있는 serverfix 라는 로걸 브 랜치가 만들어 진다. 
3.5.2 브탠 치추적 

리모트 브 랜치를 로걸 브 랜치로 Checkout 하면 자 동으로 트래킹 (Tracking) 브 랜치가 만들어 진다. 
트래킹 브탠치 는리모 트브랜 치와직 집격인 연결고 리가있 는로컬 브탠치 이다. 트래킹 브랜 치에서 git 
push 명령을 내려도 Git 은 연결 고리가 있어서 어떤 리모트 저 장소에 Push 해야 하는지 알 수 있다. 또 
한 git pull 명렁을 내리면 리모트 저장소 로부터 데 이터를 내 려받아 연결된 리모트 브 탠치와 자 동으로 
Merge 한다. 

서버 로부터 저 장소를 Clone 해올 때도 Git 은 자 동으로 master 브 랜치를 origin/master 브 랜치의 트 

래킹 브 탠치로 만 든다. 그래서 git push, git pull 명렁이 추 가적인 아 규먼트 없이 도동작 한다. 트래 

킹 브 탠치를 직집 만들 수 있는데 origin/master 뿐만 아니라 다른 저 장소의 다른 브 탠치도 추 격하게 

(Tracking) 할수 있다. git checkout -b [branch] [remotename]/[ branch] 명령 으로간 단히트 래킹브 

탠치를 만들 수 있다. Git 1 .6.2 버견 이상을 사 용하는 경 우에는 - track 옵션도 사용할 수 있다. 

$ git checkout —track origin/serverfix 

Branch serverfix set up to track remote branch serverfix from origin. 
Switched to a new branch 'serverfix' 

리모트 브 탠치와 다른 이 름으로 브 랜치를 만 들려면 로걸 브 탠치의 이름을 아래와 같이 다르게 지정한 
다: 

$ git checkout — b sf origin/serverfix 

Branch sf set up to track remote branch serverfix from origin. 
Switched to a new branch 'sf 



이제 sf 브랜치 에서 Push 나 Pull 하면 자 동으로 origin/serverfix 에 데 이터를 보내거 나가져 온다. 

3.5.3 리모 트브탠 치삭제 

동료와 협 업하기 위해 리모트 브 탠치를 만들 었다가 작업을 마치고 master 브 랜치로 Merge 했다. 협 

업하는 데 사 용했던 그 리모트 브 랜치는 이제 안 정화됐 으므로 삭제할 수 있다. git push [remotename] 

： [branch] 라고 실 행해서 삭제할 수 있는데 이명 렁은좀 특 이하게 생 겼다. serverfix 라는 리모트 브랜 
치 를삭제 하려면 다음 과같이 실행 한다: 
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$ git push origin :serverfix 
To git@github.com:schacon/simplegit .git 
- [deleted] serverf ix 



위 명렁을 실 행하고 나면 서버의 브탠치 는삭제 된다. 이 명령을 잊 어버릴 경우를 대 비해서 페이지 귀통 

이를집 어놓고 필요할 때 펴보는 게 좋 을지도 모르 겠다. 이 명렁은 앞서 살펴본 git push [remotename] 
[localbranch] ： [remotebranch] 형 식으로 기 억하는 것이 좋다. [localbranch] 부분에 비워 둔 채로 실행 
하면 '로 컬에서 빈 내용을 리 모트의 [remotebranch] 에 채워 넣 어라' 라 는뜻이 되기 때문 이다. 



3.6 Rebase 하기 

Git 에서 한 브탠 치에서 다른 브 탠치로 합치는 방법은 두 가지가 있다. 하나는 Merge 이고 다른 하나는 
Rebase 다. 이 절 에서는 Rebase 가 무엇 인지, 어떻게 사용하 는지， 좋은 점은 뭐고, 어떤 상 황에서 사용 
하고 어떤 상 황에서 사 용하지 말아야 하는지 알아 본다. 

3.6.1 Rebase 의기초 

앞의 Merge 결에서 살펴본 예제로 다시 돌아가 보자 (그림 3-27) . 두개의 나 누어진 브 탠치의 모습을 
볼수 있다. 



experiment 



I 




그림 3.27: 두 개의 브 랜치로 나 누어진 커밋 히 스토리 

이 두 브 랜치를 합치는 가장 쉬운 방법은 앞에서 살펴본 대로 Merge 명령을 사 용하는 것 이다. 두 브랜 
치의 마 지막커 밋두개 (C3， C4) 와공 통조상 (C2) 을사 용하는 3_way Merge 로그림 3-28 처럼 새로 
운 커밋을 만들어 낸다. 



， 




t 



그림 3.28: 나뉜 브 랜치를 Merge 하기 
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비숫한 결과를 만드는 다른 방식 으로， C3 에서 변경된 사항을 패치 (Patch) 로 만들고 이를 다시 C4 에 
격용 시키는 방법이 있다. Git 에서는 이런 방식을 Rebase 라고 한다. Rebase 명 렁으로 한 브탠 치에서 
변경된 사항을 다른 브 탠치에 적용할 수 있다. 
위의 예제는 다음과 같은 명 렁으로 Rebase 한다: 



$ git checkout experiment 
$ git rebase master 

First, rewinding head to replay your work on top of it... 
Applying: added staged command 



실제로 일 어나는 일을 설명 하자면 일 단두브 탠치가 나뉘기 전인 공통 커 밋으로 이 동하고 나서 그 커밋 

부터 지금 Checkout 한 브 랜치가 가 리키는 커 밋까지 diff 를 차례로 만들어 어 딘가에 임시로 저장해 놓 
는다. Rebase 할 브랜치 (역주 - experiment) 가합칠 브탠치 (역주 - master) 가가리 키는커 밋을가 
리키게 하 고아까 저장해 놓았던 변경 사항을 차례대 로적용 한다. 그림 3-29 는이 러한과 정을나 타내고 
있다. 




그림 3.29: C3 의 변경 사항을 C4 에 적 용하는 Rebase 과정 

그리고 나서 master 브 탠치를 Fast-forward 시 킨다. 



( CO ) "*ᅳ ( Cl j-*— ^ C2 》 «ᅳ ( " ) ' 

A 



그림 3.30: master 브 랜치를 Fast-forward 시키기 



C3' 로 표시된 커밋 에서의 내용은 Merge 예 제에서 살펴본 C5 커밋 에서의 내용 과같을 것 이다. Merge 
이든 Rebase 든 둘 다 합치는 관점 에서는 서로 다를 게 없다. 하 지만， Rebase 가 좀 더 깨끗한 히 스토리 
를만 든다. Rebase 한브 탠치의 Log 를 살펴보 면히스 토리가 선형적 이다. 일을 병렬로 동시에 진행해 
도 Rebase 하고 나면 모든 작업이 차 례대로 수행된 것처럼 보 인다. 

Rebase 는 보통리 모트브 탠치에 커 밋을깔 끔하게 격용하 고싶을 때사용 한다. 아마 이렇게 Rebase 하 
는 리모트 브랜치 는직접 관리하 는것이 아 니라그 낭참여 하는브 탠치일 것 이다. 메인 프로 젝트에 패치 
를보낼 준비가 되면하 는것이 Rebase 이 니까브 탠치에 서하던 일을 완견히 마치고 origin/master 로 
Rebase 한다. 프 로젝트 관 리자는 어떠한 통합 작업도 필요 없다. 그낭 master 브 탠치를 Fast—forward 
시키면 된다. 

Rebase 를 하 든지, Merge 를 하든지 초ᅵ종 결 과물은 같고 커밋 히스 토리만 다 르다는 것이 중요 하다. 
Rebase 의 경 우는브 랜치의 변경사 항을순 서대로 다른브 랜치에 적용 하면서 합치고 Merge 의 경우는 
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브 랜치의 최종결 과만을 가지고 합 친다. 



3.6.2 즘 더 Rebase 

Rebase 는 단순히 브 탠치를 합치는 것만 아니라 다른 용 도로도 사용할 수 있다. 그림 3-31 과 같은 히 
스 토리가 있다고 하자. server 브 탠치를 만 들어서 서버 기능을 추 가하고 그 브탠 치에서 다시 client 브 
탠치를 만들어 클라 이언트 기능을 추가 한다. 마지 막으로 server 브 랜치로 돌 아가서 몇 가지 기능을 더 
추가 한다. 




1 



client 



그림 3.31 ： 다른 토픽 브랜 치에서 갈라져 나온 토픽 브랜치 

이때 테 스트가 덜 된 server 브 랜치는 그대로 두고 client 브 탠치만 master 로 합 치려는 상황을 생각해 
보자. server 와는 아무 관련이 없는 client 커밋은 C8, C9 이다. 이 두 커밋을 master 브 랜치에 적용하 

기 위해서 "onto 옵 션을사 용하여 아래와 같은 명렁을 실행 한다: 



$ git rebase —onto master server client 



이 명령은 client 브 탠치를 Checkout 하고 server 와 client 의 공 통조상 이후의 패치를 만들어 master 
에 적용 한다. 조금 복 잡하긴 해도 꽤 쓸모 있다. 그림 3_32 를 보자. 
이제 master 브 탠치로 돌 아가서 Fast-forward 시길수 있다: 

$ git checkout master 
$ git merge client 

server 브 랜치의 일이다 끝나면 git rebase [basebranch] [topicbranch] 라는명 렁으로 Checkout 하 

지 않고 바로 server 브 탠치를 master 브 탠치로 rebase 할 수 있다. 이명령 은토픽 (server) 브 랜치를 
Checkout 하고 베이스 (master) 브 탠치에 Rebase 한다: 
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그림 3.32: 다 른토픽 브랜 치에서 갈라져 나 온토픽 브 랜치를 Rebase 하기 




server 



그림 3.33: master 브 랜치를 client 브랜치 위치로 진행 시키기 



$ git rebase master server 



server 브 랜치의 수정 사항을 master 브 탠치에 적용 했다. 그 결과는 그림 3-34 와 같다. 




그림 3.34: master 브 랜치에 server 브 랜치의 수정 사항을 적용 

그리고 나서 master 브 탠치를 Fast-forward 시 킨다: 

$ git checkout master 
$ git merge server 

모 든것이 master 브 탠치에 통 합됐기 때문에 더 필 요하지 않다면 client 나 server 브탠 치는삭 제해도 
된다. 브탠 치를삭 제해도 커밋히 스토리 는그림 3-35 와같이 여전히 남아 있다: 
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$ git branch — d client 
$ git branch — d server 




그림 3.35: 최종 커밋히 스토리 



3.6.3 Rebase 의우 ᅵ험성 

Rebase 가 장점이 많 은기능 이지만 단점이 없는 것은 아니니 조 심해야 한다. 그 주의 사항은 다음 한 문 
장 으로표 현할수 있다: 

이미 공개 저 장소에 Push 한 커밋을 Rebase 하지 마라 

이 지침만 지키면 Rebase 를하는 데 문제 될 게 없다. 하 지만, 이 주의 사항을 지키지 않으면 사 람들에 
게 욕을 먹을 것이다 (역주 - 아마도 가카의 호연 지기가 필 요해질 것이다 ). 
Rebase 는 기존의 커밋을 그대로 사 용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만 든다. 새 커 
밋을 서버에 Push 하고 동료 중 누 군가가 그 커밋을 Pull 해서 작업을 한다고 하자. 그런데 그 커밋을 git 
rebase 로 바꿔서 Push 해 버리면 동료가 다시 Push 했을 때 동료는 다시 Merge 해야 한다. 그리고 동료 
가 다시 Merge 한 내용을 Pull 하면 내 코드는 정말 엉망이 된다. 

이미 공개 저 장소에 Push 한 커밋을 Rebase 하면 어떤 결고ᅡ 가초래 되는지 예제 를통해 알아 보자. 중앙 
겨장 소에서 Clone 하고 일부 수정을 하면 커밋 히스 토리는 그림 3-36 과 같아 진다. 

git.teaml .ourcompany.com 



CI 1*^ master 



My Computer 




master 



그림 3.36: 저 장소를 Clone 하고 일부 수정합 



이제 팀원중 누군가 커밋, Merge 하고 나서 서버에 Push 한다. 이 리 모트브 탠치를 Fetch, Merge 하 
면그림 3-37 과같이 된다. 

그런데 Push 했던 팀원은 Merge 한 일을 되 돌리고 다시 Rebase 한다. 서버의 히 스토리 를새로 덮어씌 

우려면 git push -force 명 령을사 용해야 한다. 이후에 저장 소에서 Fetch 하 고나면 아래 그림 과같은 

상태가 된다: 
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git.team1 .ourcompany.com 




My Computer 




그림 3.37: Fetch 한후 Merge 함 



gltteaml .ourcompany.com 




그림 3.38: 한 팀원이 다른 팀원이 의 존하는 커밋을 없애고 Rebase 한 커밋을 다시 Push 함 

기존 커밋이 사 라쳤기 때문에 이미 처리한 일 이라고 해도 다시 Merge 해야 한다. Rebase 는 커밋의 
SHA-1 해시를 바꾸기 때문에 Git 은 새로운 커밋으 로생각 한다. 사실 C4 는이미 히스 토리에 격 용되어 
있 지만， Git 은모 른다. 



gltteaml .ourcompany.com 




My Computer 




teamonc/ master 



^ ( C3 ^ C7 j^— ^ C8 j-* 



그림 3.39: 같은 Merge 를 다시 한다 
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다 른개발 자와계 속같이 일 하려면 이런 Merge 도 해야만 한다. Merge 하면 C4 와 C4' 커밋들 다히스 
토리에 남게 된다. 실제 내 용과메 시지가 같지만 SHA-1 해시 값이 전혀 다 르다. git log 로히스 토리를 
확인 해보면 저자, 커밋 날짜， 메 시지가 같은 커밋이 두 개 있을 것 이다. 이렇게 되면 흔란스 럽다. 게다가 
이 히스 토리를 서버에 Push 하면 같 은커밋 이두개 있기 때문에 다른 사람들 도혼란 스러워 한다. 
Push 하기 전에 정리 하려고 Rebase 하는 것은 괜 찮다. 또 절대 공 개하지 않고 혼자 Rebase 하는 경우 
도 괜 찮다. 하 지만, 이미 공 개하여 사 람들이 사 용하는 커밋을 Rebase 하면 를 림없이 문제가 생길 것이 
다. 

3.7 요약 

우 리는이 장에서 Git 으로 브 랜치를 만들고 Merge 기능의 기 본적인 명렁을 다루 었다. 이제 브 랜치를 
만들고 옮겨 다니고 Merge 하는 것에 익숙 해쳤을 것으로 생각 한다. 브 랜치를 Push 하여 공유 하거나 
Push 하기 전에 브 탠치를 Rebase 하는 것 정도는 어렵지 않게 할 수 있을 것 이다. 
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이글 을읽는 독 자라면 이 미하루 업무의 대 부분을 Git 으로 처 리할 수 있을 거 라고 생각 한다. 이제는 다 
른사 람과협 업하는 방법을 고민해 보자. 다 른사람 과협업 하려면 리모트 저장소 가필요 하다. 물 론혼자 
서 저 장소를 만들고 거기에 Push 하고 Pull 할수도 있지만 이렇게 하는 것은 아무 의미가 없다. 이런 방 
식 으로는 다른 사람이 무슨 일을 하고 있는지 알려면 항상 지 켜보고 있어야 간신히 알 수 있을 터 이다. 
당신 컴 퓨터가 오프 라인일 때에도 동료가 저 장소를 사용할 수 있도록 언제나 이용할 수 있는 저 장소가 
필요 하다. 즉, 공 동으로 사용할 수 있는 저 장소를 만들고 모두 이 저 장소에 집 근하여 Push, Pull 할 수 
있어야 한다. 우 리는이 저 장소를 "Git 서버" 라고부 른다. Git 저장소 를운영 하는데 자원이 많이 필요하 
지도 않아서 별도로 Git 서버를 준 비하지 않아도 된다. 

Git 서버를 운 영하는 것은 어렵지 않다. 우선 사용할 전송 프로토 콜부터 정 한다. 이 장의 앞부분 에서는 
어떤 프로 토콜이 있는지 그리고 각 장 단점은 무 엇인지 살펴 본다. 그 다음엔 각 프로 토콜을 사 용하는 방 
법과 그 프로 토콜을 사용할 수 있도록 서버를 구 성하는 방법을 살펴 본다. □ ᅡ지 막으로 다른 사람의 서 버 
에 내 코드를 말기긴 싫고 고생 스럽게 서버를 설 치하고 관 리하고 싶지도 않을 때 고를 수 있는 선 택지가 
어떤 것들이 있는지 살펴 본다. 

서버 를직집 설 치해서 운영할 생각이 없으면 이 장의 마지 막결만 읽어도 된다. 마 지막질 에서는 Git 호 
스팅 서 비스에 계정을 만들고 사 용하는 방법에 대해 설명 한다. 그리고 다음 장 에서는 분산 환 경에서 소 

스를 관 리하는 다양한 패턴에 대해 논의할 것 이다. 

리모트 저 장소는 일반 격으로 워킹 디텍 토리가 없는 Bare 저장소 이다. 이 겨장소 는협업 용이기 때문에 
체크 아웃이 필요 없다. 그낭 Git 데 이터만 있으면 된다. 다시 말해서 Bare 저 장소는 일반 프로젝 트에서 
.g it 디텍토 리만있 는저장 소다. 



4.1 프 로토콜 

Git 은 Local, SSH, Git, HTTP 이렇게 네 가지의 네 트워크 프로 토콜을 사용할 수 있다. 이 절 에서는 각 
각 어떤 경우에 유 용한지 살펴볼 것 이다. 

HTTP 프로 토콜을 제외한 나머 지들은 모두 GitO| 서버에 설치돼 있어야 한다. 
4.1.1 로걸프 로토콜 

가장기 본격인 것이 로걸 프 로토클 이다. 리모트 저 장소가 단순히 디 스크의 다른 디텍 토리에 있을 때 사 
용 한다. 팀 원들이 견부 한 시 스템에 로그 인하여 개발 하거나 아니면 NFS 같은 것으로 파일시 스템을 공 
유하고 있을 때 사용 한다. 전자는 문제가 될 수 있다. 모든 겨 장소가 한 시 스템에 있기 때문에 한 순간에 
모두 잃을수 있다. 
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공유 파일시 스템을 마운 트했을 때는 로컬 저 장소를 사 용하는 것처럼 Clone 하고 Push 하고 Pull 하면 
된다. 일단저 장소를 Clone 하거 나프로 젝트에 리모트 저장소 로추가 한다. 추 가할때 URL 자리에 저장 
소의 경로 를사용 한다. 예 를들어 아래 와같이 로컬 저 장소를 Clone 한다: 



$ git clone /opt/git/project .git 



아 래처럼 도가능 하다: 



$ git clone file: ///opt/git/project .git 



Git 은파일 경로 를직집 쏠때와 file:// 로시 작하는 URL 을사용 할때에 약간 다르게 처리 한다. 디텍토 
리 경로를 사 용해서 같은 파일시 스렘에 있는 저 장소를 Clone 할 때 Git 은 하드 링크를 만 든다. 같은 파일 
시 스템에 있는게 아니면 그 낭복사 한다. 하지만 file:// 로시 작하면 Git 은네트 워크를 통해서 데 이터를 
견송할 때처럼 프로 세스를 별도로 생 성하여 처리 한다. 이 프로 세스로 데 이터를 견 송하는 것은 효율이 
좀떨어 지지만 그래도 file:// 를사 용하는 이유가 있다. 보통은 다른버 전관리 시스템 들에서 임 포트한 
후에 이렇게 사용하 는데， 외부 레퍼 런스나 개 체들이 포함된 저 장소의 복 사본을 깨끗한 상태로 남겨두 
고 자할때 사 용한다 (9 장에서 자세히 다툰다 ). 여기서 는속도 가빠른 디 텍토리 경로 를사용 한다. 
이미 있는 Git 프로젝 트에서 아래와 같이 로컬 저 장소를 추가 한다: 



$ git remote add local— proj / opt/git/ proj ect . git 



그러면 네트 워크에 있는 리모트 저장 소처럼 Push 하고 Pull 할 수 있다. 
장점 

파일 기반 저 장소는 단순한 것이 장점 이다. 기존에 있던 네트 워크나 파일의 권한을 그대로 사 용하기 때 
문에설 정하기 쉽다. 이미 팀견체 가접근 가능한 파일시 스렘이 있으 면저장 소를아 주쉽게 구성 할수있 
다. 디텍 토리를 공유 하듯이 동료가 모두 읽고 쏠수있 는공유 디텍 토리에 Bare 겨 장소를 만 든다. 다음 
결인 "서 버에 Git 설치 하기" 에서 Bare 저 장소를 만드는 방법을 살펴볼 것 이다. 
또한， 동료가 작 업하는 저장 소에서 한 일을 바로 가겨오 기에도 좋다. 만약 함깨 프로 젝트를 하는 동료 
가자 신이 한 일을 당신이 확인해 줬으면 한다. 이럴 때그 동료가 서버에 Push 하고 당신이 다시 Pull 할 

필 요없이 git pull /home/john/project 라는 명 령어를 바로 실행 시켜서 매우 쉽게 동료의 코드를 가겨 
올수 있다. 

단점 

다 양한상 황에서 집 근할수 있도록 디 텍토리 를공유 하는것 자체가 일반적 으로어 렵다. 집에 있을때 
Push 하려면 리모트 저 장소가 있는 디 스크를 마운 트해야 하는데 이것은 다른 프로토 콜을이 용하는 방 
법 보다느 리고어 렵다. 

게다가 네 트워크 파일시 스템을 마운 트해서 사 용하는 중 이라면 별로 빠 르지도 않다. 로컬 저 장소는 데 
이터를 빠르게 읽을 수 있을 때만 빠 르다. NFS 에 있는 겨 장소에 Git 을 사 용하는 것은 보통 같은 서버에 
SSH 로접근 하는것 보다느 리다. 
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4.1 절 프로토 



4.1.2 SSH 프 로토콜 

Git 의 대 표프로 토콜은 SSH 이다. 대부분 서버는 SSH 로집 근할수 있도록 설정돼 있다. 뭐, 설정돼 있 
지 않 더라도 쉽게 설정할 수 있다. 그리고 SSH 는 읽기 / 쓰기 집근을 쉽게 할 수 있는 유일한 네 트워크 프 
로토콜 이다. 다른 네 트워크 프로 토콜인 HTTP 와 Git 은 일반 적으로 읽기만 가능 하다. 그래서 초보자 
(unwashed masses) 라고해 도쓰기 명령 을이용 하려면 SSH 가필요 하다. SSH 는또 한인증 도지원 
한다. SSH 는보 통유비 쿼터스 격이면 서도， 사용하 기도, 설치 하기도 쉽다. 
SSH 를통해 Git 저 장소를 Clone 하려면 ssh:// 로시 작하는 URL 을사용 한다: 



$ git clone ssh ： //user@server/proj ect . git 




아니면 scp 명령 어처럼 사 용할수 있다. 이게 조금 더 짧다: 



$ git clone user@server ： proj ect . git 




사용자 계정을 생락할 수도 있는데 게정을 생 락하면 Git 은 현재 로 그인한 사 용자의 계정을 사용 한다. 



장점 

SSH 는 장점이 매우 많은프 로토콜 이다. 첫째, 누가 리모 트에서 저 장소에 집근 하는지 알고 싶다면 SSH 
를사 용해야 한다. 들째， SSH 는 상대격 으로설 정하기 쉽다. SSH 데돈은 정말흔 하다. 네 트워크 관리자 
은 SSH 데몬을 다 루어본 경험이 있고 대 부분의 OS 배포 판에는 SSH 데돈과 관리도 구가모 두들어 있 
다. 셋째, SSH 를 통해 집 근하면 보안에 안전 하다. 모든 데 이터는 암호 화되어 인증된 상태로 전송 된다. 
마지 막으로 SSH 는 견송 시 데 이터를 가능한 압 축하기 때문에 효을격 이다. 

단점 

SSH 의 단 점은익 명으로 집근할 수 없다는 것 이다. 심지어 읽기 견용인 경 우에도 익 명으로 시 스템에 
집근할 수 없다. 회사 에서만 사용할 것 이라면 SSH 가 가장 적합한 프로 토콜일 것 이지만 오 픈소스 프로 
젝트는 SSH 만 으로는 부족 하다. 만약 사 람들이 프로 젝트에 익 명으로 집근할 수 있게 하 려면, 자신이 
Push 할 때 사용할 SSH 를 설 치하는 것과 별개로 다른 사 람들이 Pull 할 때 사용할 다른 프로 토클을 추가 
해야 한다. 



4.1.3 Git 프 로토콜 

Git 프로 토콜은 Git 에 포함된 데몬을 사 용하는 방법 이다. 포트는 941 8 이며 SSH 프로 토콜과 비숫한 
서 비스를 제공하 지만, 인 증메커 니즘이 없다. 저 장소에 git-export-daemon-ok 파일을 만들면 Git 
프로 토콜로 서 비스할 수 있 지만, 보안은 없다. 이 파일이 없는 저 장소는 Git 프로 토콜로 서 비스할 수 없 
다. 이 저 장소는 누구나 Clone 할 수 있거나 아무도 Clone 할 수 없거나 들 중의 하나만 선택할 수 있다. 
그래서 이 프로토 클로는 Push 가 능하게 설정할 수 없다. 엄밀히 말해서 Push 할 수 있도록 설정할 수 
있 지만， 인 증하도 록할수 없다. 그 러니까 당신이 Push 할수 있으면 이 프로 젝트의 URL 을아는 사람은 
누구나 Push 할 수 있다. 그 낭이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다. 
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장점 

Git 프로 토콜은 견송 속도가 가장 빠 르다. 견 송량이 많은 공개 프로 젝트나 별도의 인증이 필요 없고 읽 
기만 허 용하는 프로 젝트를 서 비스할 때 유용 하다. 암 호화와 인증을 빼면 SSH 프로 토콜과 견송 메커니 
즘 이별반 다르지 않다. 

단점 

Git 프로토 콜은인 증메커 니즘이 없는게 단점이 다. Git 프 로토클 만사용 하는프 로젝트 는바람 직하지 
못 하다. 일반 적으로 SSH 프로 토콜과 함깨 사용 한다. 소수의 개 발자만 Push 할 수 있고 대다수 사람은 
git:// 을 사 용하여 얽을 수만 있게 한다. 어쩌면 가장 설 치하기 어려운 방법일 수도 있다. 별도의 데몬 
이 필 요하고 프로 젝트에 맞게 설 정해야 한다. 이 장의 Gitosis 절에서 설 정하는 법을 살펴볼 것 이다. 자 
원을 아낄 수 있도록 xinetd 같은 것도 설 정해야 하고 방 화벽을 통과할 수 있도록 941 8 포트도 열어야 
한다. 이 포트는 일반 적으로 회 사들이 허 용하는 표준 포트가 아 니다. 규모가 큰 회 사라면 당연히 방화 
벽에서 이 포트를 막아놓 는다. 

4.1.4 HTTP/S 프 로토콜 

마지막 으로， HTTP 프로 토콜이 있다. HTTP 와 HTTPS 프로 토콜의 미학은 설정이 간단하 다는점 이다. 
HTTP 도큐 먼트루 트밑에 Bare 저장소 를두고 post-update 흑을 설정하 는것이 기본 적으로 해야하 
는 일의 견부다 (7 장에서 Git 흑에 대해 자세히 다룰 것이다 ). 저 장소가 있는 웹 서버에 접근할 수 있다 
면 그 저 장소를 Clone 할 수도 있다. HTTP 를 통해서 저 장소를 읽을 수 있게 하려면 아래와 같이 한다: 

$ cd /var/www/htdocs/ 

$ git clone ―— bare /path/to/git_project gitproject.git 
$ cd gitproject.git 

$ mv hooks/post— update. sample hooks/post-update 
$ chmod a+x hooks/post-update 

post-update 흑은 Git 에 포 함되어 있으며 git update-server-info 라는 명 렁어를 실행시 킨다. 이 명 
령어는 HTTP 로 Fetch 와 Clone 명 령이잘 동 작하게 한다. SSH 를 통해서 겨 장소에 Push 할 때 실행되 
며, 사 람들은 아래와 같이 Clone 한다: 



$ git clone http://example.com/gitproject.git 



여 기서는 Apache 서버가 기 본으로 사 용하는 /var/mw/htdocs 을 루트 디텍 토리로 사용 하지만 다른 웹 
서 버를사 용해도 된다. 단순히 Bare 저 장소를 HTTP 문서 루트에 넣으면 된다. Git 데 이터는 일 반적인 
정격 파 일처럼 취 급된다 (9 장에서 정확히 어떻게 처리 하는지 다룰 것이다 ). 

HTTP 를 통해서 Push 하는것 도가능 하다. 단지 이 방법 은잘사 용하지 않는 WebDAV 환경을 완벽하 
게 구 축해야 한다. 잘사 용하지 않기 때문에 이 책 에서도 다루지 않 는다. HTTP 프로 토콜로 Push 하고 
싶으면 http ： I /www . kernel . org/pub/ software/scm/git/docs/howto/ setup ᅳ git— server— over— http . txt 읽 
고 저 장소를 만들면 된다. HTTP 를 통해서 Push 하는 방법의 좋은 점은 WebDAV 서버를 아 무거나 골 
라쓸수 있다는 것 이다. 그래서 WebDAV 를 지 원하는 웸 호스팅 업체를 이 용하면 이 기능을 사용할 수 
있다. 
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4.2 절 서버에 Git 설 치하기 



장점 

HTTP 프로토 콜은설 정하기 쉽다 는것이 장점 이다. 몇개의 필수명 령어만 실행하 면세계 어 디에서 
나 당신의 저 장소에 집근할 수 있게 만들 수 있다. 이렇게 하는데 S 분이면 충분 하다. HTTP 프 로토클 
은 서버의 리소스 를많이 캅아먹 지도않 는다. 보통 은정적 HTTP 서 버만으 로도충 분하기 때문 에흔한 
Apache 서버로 초당 수천 개의 파일을 처리할 수 있다. 작은 서 버로도 충분히 감당할 수 있다. 
또 HTTPS 를 사 용해서 서 비스할 수도 있기 때문에 견 송하는 데 이터를 암 호화할 수 있다. 그리고 클라 
이 언트가 서명된 SSL 인증 서를사 용하게 할수도 있다. 이렇게 하 더라도 SSH 공개 키를사 용하는 방식 
보다 쉽다. 서명한 SSL 인증서 를사용 하는게 나 을때도 있고 단순히 HTTPS 위에서 HTTP 기반 인증을 
사용 하는게 Lh 을때도 있다. 

HTTP 는 매우 보 편적인 프 로토콜 이라서 거의 모든 회사가 트 래픽이 방 화벽을 통과 하도록 허용 한다는 
장점도 있다. 



단점 

클라 이언트 에서는 HTTP 가 좀 비 효율적 이다. 저장 소에서 Fetch 하거나 Clone 할 때 좀 더 오래 걸린 
다. 다튼 프로 토클의 네 트워크 오버헤 드보다 HTTP 의 오버 해드가 좀 더 크다. 지능 적으로 정말 필요 
한 데 이터만 전 송하지 않기 때문에 HTTP 프로 토콜은 S 청한 프 로토콜 (Dumb Protocol) 이 라고도 부 
른다. 효을 적으로 견송 하고자 서버는 아 무것도 하지 않 는다. HTTP 와 다른 프로 토콜의 성능 차이는 9 
장에서 자세히 설명 한다. 



4.2 서버에 Git 설 치하기 

어떤 서버를 설치하 더라도 일단 저 장소를 Bare 저 장소로 만 들어야 한다. 다시 말하지 만, Bare 겨장소 
는 워킹 디텍 토리가 없는 저장소 이다. -bare 옵션을 주고 Clone 하면 새로운 Bare 겨 장소가 만 들어진 
다. Bare 겨장소 디텍 토리는 관례에 따라. git 확장 자로끝 난다: 

$ git clone ―— bare my_project my .project. git 
Cloning into bare repository 'my_project.git' . . . 
done. 



이 명령이 출 력하는 메 시지가 조금 이상 해보일 수도 있다. 사실 git clone 명령은 git init 을 하고 나서 
git fetch 를실행 한다. 그런데 빈 디텍토 리밖에 만들지 않는 git init 명령의 메시지 만보여 준다. 개체 
견송에 관런된 메시지 는아무 것도보 여주지 않 는다. 견 송메시 지를보 여주지 않지만 my— project. git 디 
롁토리 를보면 Git 데이터 가들어 있다. 
아래와 같이실 행한것 과비숫 하다: 



$ cp -Rf my— project/. git my_project.git 



물론 설정 상의 미세한 차이가 있 지만, 저 장소의 내용만 고려 한다면 같다고 볼 수 있다. 워킹 디 텍토리 
가 없는 Git 저 장소인 데다가 별도의 디텍 토리도 하나 만들 었다는 점 에서는 같다. 
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4.2.1 서버에 Bare 저장 소넣기 

Bare 저 장소는 이제 만들었 으니까 서버에 넣고 프로 토콜을 설정 한다. git. example. com 라는 이름의 서 
버를 하나 준 U I 하자. 그리고 그 서버에 SSH 로 집속할 수 있게 하고 /opt/git 에 Git 저 장소를 만 든다. 아 
래와 같이 Bare 겨 장소를 복사 한다: 



$ scp — r my— project. git user@git . example . com ： / opt/git 



이제 다른 사용 자들은 SSH 로 서버에 집 근해서 겨 장소를 Clone 할 수 있다. 사 용차는 /opt/git 디롁토 
리 에읽기 권한이 있어야 한다: 



$ git clone user@git.example.com: /opt/git/my— project. git 



이 서버에 SSH 로 집 근할수 있는사 용자가 /opt/git/ my _pro;ject.git 디롁 토리에 쓰기 권 한까지 가지고 
있으 면바로 Push 할수 있다. git init 명령에 —shared 옵 션을추 가하면 Git 은 자동으 로그룹 쓰기권 
한 을추가 한다: 

$ ssh user@git.example.com 
$ cd /opt/git/my— project. git 
$ git init ―— bare —shared 

Git 저 장소를 만드는 것이 얼마나 쉬운지 살펴보 았다. Bare 겨 장소를 만들어 SSH 로 집근할 수 있는 서 
버에 올리면 동료와 함께 일할 준비가 끝 난다. 

그 러니까 Git 서버를 구축 하는데 사람이 할 일은 정말 별로 없다. SSH 로 접속할 수 있도록 서버에 계정 
을 만들고 Bare 저 장소를 사 람들이 읽고 쏠 수있는 곳에 넣어 두기만 하면 된다. 다른 것은 아 무것도 필 
요 없다. 

다음 결 에서는 좀 더 정 교하게 설 정하는 법을 살펴 본다. 사용 자에게 계정을 만들어 주는 법, 저 장소를 
읽고 쓸 수 있게 하는 법， Web UI 를 설 정하는 법, Gitosis 를사 용하는 법, 등등은 여 기에서 설 명하지 않 
는다. 꼭기 억해야 할 것은 동료 와함께 개발할 때 꼭 필요한 것이 SSH 서버와 Bare 저 장소뿐 이라는 것 
이다. 

4.2.2 바로설 정하기 

만약 창업을 준 비하고 있거나 회 사에서 Git 을 막 도입 하려고 할 때처럼 사용할 개 발자의 수가 많지 않 
을 때에는 설정할 게 별로 없다. Git 서버 설 정에서 사용자 관리가 가장 골치 아 프다. 사람이 많으면 어 
떤 사 용자는 읽기만 가 능하게 하고 어떤 사 용자는 읽고 쓰 기둘다 가 능하게 하는 것이 좀 까다 롭다. 

SSH 접근 

만약 모든 개 발자가 SSH 로 접속할 수 있는 서버가 있으면 너무 쉽게 저 장소를 만들 수 있다. 앞서 말했 
듯이 할 일이 별로 없다. 저 장소의 권 한을꼼 꼼하게 관리해 야하면 그 낭운영 체제의 파일 시스템 권한관 
리를 이용 한다. 동료가 저 장소에 쓰기 집근을 해야 하는 데 아직 SSH 로 집속할 수 있는 서버가 없으면 
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하나마 련해야 한다. 아 마독자 에게서 버가있 다면그 서버에 는이미 SSH 서버가 설치돼 있어서 이미 
SSH 로집 속하고 있을것 이다. 

동료가 접속 하도록 하는 방법은 S 가지가 있다. 첫째로 모 두에게 계정을 만들어 주는 방법이 있다. 이 
방법이 제일 단순하 지만다 소귀찮 은방법 이다. 팀 원마다 adduser 를실 행시키 고임시 암호를 부여해 
야 하기 때문에 보통 이 방법을 쓰고 싶어 하지 않 는다. 

둘 째로서 버마다 git 이라는 게정을 하나씩 만드는 방법이 있다. 쓰기 권한이 필 요한사 용자의 SSH 공 
개키를 모두 모아서 git 계정의 ~/ .ssh/authorized— keys 파일에 모든 키를 입력 한다. 그러면 모두 git 계 
정으로 그 서버에 집속할 수 있다. 이 git 계정은 커밋 데이 터에는 아무런 영향을 주지 않 는다. 다시 말 
해서 집 속하는 데 사용한 SSH 계정과 커밋에 저 장되는 사 용자는 아무 상관 없다. 
이미 LDAP 서버 같 은중앙 집중식 인증 소스를 가지고 있으면 SSH 서버 가해당 인증을 이용하 도록할 
수도 있다. SSH 인증 메 커니즘 중 아무거 나하나 이용할 수 있으면 그 서버에 집속이 가능 하다. 

4.3 SSH 공개키 만들기 

이미 말 했듯이 많은 Git 서 버들은 SSH 공개키 로인증 한다. 공개키 를사용 하려면 일단 공개키 를만들 
어야 한다. 공 개키를 만드는 방법은 모든 운영 체제가 비숫 하다. 먼저 키가 있는 지부터 확인 하차. 사용 
자의 SSH 키들은 기본격 으로사 용자의 ~/. SS h 디텍 토리에 저장 한다. 그래서 만약 디텍 토리의 파일을 
살 펴보면 공 개키가 있는지 확인할 수 있다: 



$ cd ~/.ssh 




$ Is 




authorized_keys2 


id_dsa known— hosts 


config 


id_dsa.pub 



something, something. pub 이라는 형 식으로 된 파일을 볼 수 있다. something 은 보통 id_dsa 나 
id— rsa 라고돼 있다. 그중 .pub 파일이 공개 키이고 다른 파일은 개인키 이다. 만약이 파일이 없거나 .ssh 
디텍 토리도 없으면 ssh-keygen 이라는 프로그 램으로 키를 생 성해야 한다. ssh-keygen 프로 그램은 리눅 
스나 Mac 의 SSH 패 키지에 포함돼 있고 윈도는 MSysGit 패키지 안에 들어 있다: 



$ ssh-keygen 

Generating public/private rsa key pair. 

Enter file in which to save the key (/Users/schacon/.ssh/id_rsa) ： 
Enter passphrase (empty for no passphrase) ： 
Enter same passphrase again: 

Your identification has been saved in /Users/schacon/ . ssh/id_rsa . 
Your public key has been saved in /Users/schacon/ . ssh/ id_rsa . pub . 
The key fingerprint is: 

43:c5:5b:5f :b1 :f1 ： 50:43： ad :20:a6 :92:6a: 1f :9a :3a schacon@agadorlaptop. local 



먼저 키를 어디에 저 장할지 경로를 (.ssh/icLrsa) 입 력하고 암호 를두번 입력 한다. 이때 암호를 비워두 
면키를 사용할 때 암호를 묻지 않 는다. 

사 용자는 그 다음에 자신의 공 개기를 Git 서버 관리 자에게 보내야 한다. 사 용자는 . pub 파일의 내용을 
복 사하여 메일을 보내기 만하면 된다. 공개키 는아래 와같이 생 겼다: 
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$ cat 〜/.ssh/id_rsa.pub 

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU 

GPl+nafzlHDTYW7hdI4yZ5ew183H43W9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3 

Pbv7kOdO/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA 

t3Fao3oAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQ3KprrX88XypNDvjYNby6vw/Pb0rwert/En 

rnZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSs 

NrRFi9wrf+M7Q= schacon@agadorlaptop . local 



다양한 운영 체 제에서 SSH 키를 만드는 방법이 긍 금하면 에 있는 Github 설 명서를 찾 아보는 게 좋다. 

4.4 서 버에설 정하기 

서버에 설 정하는 일을 살펴 보자. 일단 Ubuntu 같은 표준 리눅스 배 포판을 사용 한다고 가정 한다. 사 

용차는 아마도 authorized—keys 파일로 인증할 것 이다. 먼겨 git 계정을 만들고 사용자 홍 디텍 토리에 
.SSh 디텍토 리를만 든다: 

$ sudo adduser git 
$ su git 
$ cd 

$ mkdir .ssh 



authorizecLkeys 파일에 SSH 공 개키를 추가해 야사용 자가집 근할수 있다. 추 가하기 전에 이미 이메일 
로 공 개키를 몇 개 받아서 가지고 있다고 가정 하자. 공 개키가 어떻게 생 겄는지 다시 한번 확인 한다: 

$ cat /tmp/id_rsa . john . pub 

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L 
ojG6rs6hPB09j9R/T17/x4lhGA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k 
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez 
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6GLtPofwFBlgc+myiv 
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ynijaNsHT4kgtZg2AYYgPq 
dAv83gg3ICUvax2T9va5 gsg-keypair 



authorized_keys 파일에 추가 한다: 



$ cat /tmp/id_rsa. john. pub » 〜/.ssh/authorized— keys 
$ cat / tmp/id_rsa . j osie . pub » 〜/.ssh/authorized_keys 
$ cat /tmp/id_rsa. Jessica. pub » 〜/.ssh/authorized— keys 




--bare 옵션을 주고 git init 을 실 행해서 워킹 디텍 토리가 없는 빈 저 장소를 하나 만 든다: 
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$ cd /opt/git 
$ mkdir project. git 
$ cd project. git 
$ git ―— bare init 



이제 John 씨， Josie 씨， Jessica 씨는 이 저 장소를 리모트 저 장소로 등 록하면 브 탠치를 Push 할 수 있 
다. 프로젝 트마다 적어도 한명은 서버에 집 속하여 Bare 저장 소를만 들어야 한다. git 계 정과저 장소를 

만든 서버의 호스트 이름이 gitserver 라고 하자. 만약 이 서버가 내 부망에 있으면 gitserver 가 그서버 
를 가리 키도록 DNS 에 설정 한다. 그러면 명렁을 아래와 같이 사용할 수 있다: 

# on Johns computer 
$ cd myproject 
$ git init 
$ git add . 

$ git commit -m 1 initial commit 1 

$ git remote add origin git@gitserver: /opt/git/project. git 
$ git push origin master 




이제 이 프로 젝트를 Clone 하고 나서 수 정하고 Push 한다: 



$ git clone git@gitserver:/opt/git/project.git 
$ cd project 
$ vim README 

$ git commit —am 'fix for the README file 1 
$ git push origin master 

개발 자들이 읽고 쏠 수있는 Git 서버를 간 단하게 만들 었다. 

그리고 git— shell 이라는 걸 사 용해서 보안을 강화할 수 있다. 이 쉘로 git 계정을 사 용하는 사용 자들이 
Git 말고 다른 것을 할 수 없도록 제 한하는 것 이다. git 게정의 로그인 쉘을 이 것으로 설 정하면 git 사용 
자는 일 반적인 쉘을 사용할 수 없다. 통상의 bash, CSh 대신에 git-shell 을 로그인 쉘로 설정 하기만 하 
면 된다. 이것을 하려면 /etc/passwd 파일 을편집 한다: 

$ sudo vim /etc/passwd 



그리 고아래 와같은 줄을찾 는다: 

git :x: 1000： 1 000 ： ： /home/git ： /bin/sh 
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/bin/sh 를 /usr/bin/git— shell 로 (which git-shell 명 령으로 어디에 설치 됐는지 확인 하는게 좋다) 변경 
한다: 



git :x: 1000： 1 000 ： ： /home/git ： /usr/bin/git— shell 



이제 git 계정은 Git 저 장소에 Push 하고 Pull 하는 것만 가 능하고 서버의 쉘에는 집근할 수 없다. 실제 
로 로 그인을 해보면 아래와 같은 메 시지로 로 그인이 거결 된다: 

$ ssh git@gitserver 

fatal: What do you think I am? A shell? 
Connection to gitserver closed. 



4.5 공 개하기 

익명의 사용 자에게 읽기 집근을 허 용하고 싶을 때는 어떻게 해야 할까? 프로 젝트를 비 공개가 아니라 

오픈 소스 프로 젝트로 공개 한다거 나자동 빌드 서버나 CKContinuous Integration) 서버가 많아서 
계정 마다하 나하나 설 정해야 할 수 있다. 아니면 그낭 매번 SSH 키를 생 성하는 게 귀찮을 수도 있다. 그 
러니까 그낭 간 단하게 익명의 사 용자도 읽을 수 있도록 하고 싶을 때는 어떻게 해야 할까? 
분명웹 서버를 설치하 는것이 가장쉬 운방법 이다. 이 장의첫 부분에 설 명했듯 이웹서 버를설 치하고 
Git 저 장소를 문서 루트 디텍 토리에 두고 post-update 흑을 켜기만 하면 된다. 먼저 설 명했던 예제를 따 

라 해 보자. /opt/git 디텍 토리에 저 장소가 있고 서버에 Apache 가 설치돼 있다고 가정 하자. 아무 웸 서 
버나 다 사용할 수 있 지만, 이 예제 에서는 Apache 를 사용 한다. 여기 에서는 이 해하는 것이 목격 이므로 
아주 기 본격인 Apache 설 정만을 보여줄 것 이다. 
먼저이 흑을설 정해야 한다: 



$ cd project. git 

$ mv hooks/post— update. sample hooks/post-update 
$ chmod a+x hooks/post— update 




post-update 흑은 무슨 일을 할까? 기본 격으로 다음과 같다: 



$ cat .git/hooks/post-update 
#! /bin/sh 

# 

# An example hook script to prepare a packed repository for use over 

# dumb transports. 
# 

# To enable this hook, rename this file to "post-update" . 
# 
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exec git— update— server— info 



SSH 를 통해서 서버에 Push 하면 Git 은이 명렁 어를실 행하여 HTTP 를통 해서도 Fetch 할수 있도록 
파일 를갱신 한다. 

그다음 Apache 설정에 VirtualHost 항목을 추가 한다. 이 항 목에서 문서 루트가 Git 저 장소의 루트 디 

롁 토리가 되도록 한다. 그리고 *.git S en/er 로집속 하는사 람들이 모두이 서버에 집속 하도록 한다. 와 

일드 카드를 이 용하여 VirtualHost 항목을 아래와 같이 설정 한다: 

<VirtualHost *：80> 

ServerName git.gitserver 
DocumentRoot /opt/git 
<Directory /opt/git/> 
Order allow, deny 
allow from all 
</Directory> 
</VirtualHost> 



그리고 Apache 서버는 www-data 권 한으로 CGI 스 크립트 를실행 시키기 때문에 /opt/git 디텍 토리의 
그룹 소유 권한을 w-data 로 수정해 주어야 웹 서버로 접 근하는 사용 차들이 읽을 수 있다. 



$ chgrp -R www-data /opt/git 



Apache 를 재시 작하면 아래와 같은 URL 로 저 장소를 Clone 할 수 있다: 



$ git clone http ： / /git . gitserver/proj ect . git 



이렇게 사용 자들이 HTTP 로 프로 젝트에 집근 하도록 설 정하는 데 몇 분밖에 걸리지 않 는다. 그리고 Git 

데돈 으로도 똑같이 인증 없이 집 속하게 할 수 있다. 프로 세스를 데 돈으로 만 들어야 한다는 단점이 있지 
만 가능 하다. 이것은 다음 결에서 살펴볼 것 이다. 

4.6 GitWeb 

프 로젝트 저 장소를 단순히 읽거나 쓰는 것에 대한 설정은 다 뤘다. 이제는 웹 기반 인터페 이스를 설정해 

보자. Git 에는 GitWeb 이라는 CGI 스크 립트를 제 공해서 쉽게 웹에서 겨 장소를 조회 하도록 할 수 있다. 
같 은사이 트에서 GitWeb 을 구경할 수 있다 (그림 4-1 ). 

Git 은 GitWeb 을 쉽게 사용해 볼 수 있도록 서버를 잠시 띄우는 명렁을 제공 한다. 시 스템에 lighttpd 나 
webrick 같은 경량웹 서버가 설치돼 있 어야이 명 렁을사 용할수 있다. 리눅스 에서는 lighttpd 가설치 
돼 있 을확를 이높고 프로젝 트디렉 토리에 서그낭 git instaweb 을실행 하면바 로실행 된다. Mac 의 

Leopard 버전은 Ruby 가미리 설치돼 있기 때문에 webrick 이 더 낫다. lighttpd 이 아 니라면 아 래와같 

이 --httpd 옵 션을사 용해야 한다: 
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$ git instaweb ― httpd=webrick 
[2009-02-21 10：02：21] INFO WEBrick 1 .3.1 

[2009-02-21 10：02：21] INFO ruby 1.8.6 (2008—03—03) [universal— darwin9.0] 

1234 포트로 HTTPD 서버를 시작하 고이페 이지를 여는웰 브라우 저를자 동으로 실행시 킨다. 꾀 ] 편리 
하다. 필요한 일을 모두 마치고 나서 같은 명 렁어에 -stop 웁션을 추 가하여 서버를 중지 한다: 

$ git instaweb ―— httpd=webrick ―— stop 

항 상집속 가능한 웹인터 페이스 를운영 하려면 먼저 웹 서버에 이 CGI 스크립 트를설 치해야 한다. apt 나 
yum 으로도 gitweb 을 설치할 수 있 지만， 여기 에서는 수 동으로 설치 한다. 먼저 GitWeb 이 포함된 Git 소 
스 코드를 구한 다음 CGI 스크 립트를 빌드 한다: 

$ git clone git://git. kernel. Mg/pub/scm/git/git. git 
$ cd git/ 

$ make GITWEB_PR03 ECTR00T=" /opt/git " \ 
pref ix=/usr gitweb/gitweb.cgi 
$ sudo cp — Rf gitweb /var/www/ 

빌드할 때 gitweb— pro]ectroot 변수로 Git 저 장소의 위치를 알 려줘야 한다. 이제 Apache 가 이 스크립 
트를 사용 하도록 VirtualHost 항목을 설정 한다: 

<VirtualHost *:80> 

ServerName gitserver 
DocumentRoot /var/www/gitweb 
<Directory /var/www/gitweb> 
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그림 4.1: Git 웹용 Ul, GitWeb 
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Options ExecCGI +FollowSymLinks +SymLinksIfOwnerlilatch 
AllowOverride All 
order allow, deny 
Allow from all 
AddHandler cgi— script cgi 
Directorylndex gitweb.cgi 
</Directory> 
</VirtualHost> 



다시 말해서 GitWeb 은 CGI 를 지 원하는 웹서 버라면 아 무거나 사용할 수 있다. 이제 에 접 속하여 온라 
인으로 저 장소를 확인할 수 있을 뿐만 아니라 를 통해서 HTTP 프로 토클로 저 장소를 Clone 하고 Fetch 
할수 있다. 



4.7 Gitosis 

처 음에는 모든 사 용자의 공 개키를 authorized— keys 에 저 장하는 방법 으로도 불 편하지 않을 것 이다. 하 
지만， 사 용자가 수백 명이 넘으면 관리 하기가 매우 고통스 립다. 사 용자를 추가할 때마다 매번 서버에 집 
속할 수도 없고 권한 관리도 안 된다. authorized—keys 에 등록된 모든 사 용자는 누구나 프로 젝트를 읽고 
쏠수 있다. 

이 문제는 매우 널리 사 용되고 있는 Gitosis 라는 소프트 웨어로 해결할 수 있다. Gitosis 는 기본 격으로 

authorized.keys 파일을 관리하 고집근 제어를 돕는스 크립트 패키지 다. 사용 자를추 가하고 권한 을관리 

하는 UI 가웹 인터페 이스가 아니라 일종의 Git 저 장소라 는점이 재미 있다. 프 로젝트 설정을 Push 하면 
그 설정이 Gitosis 에 격용 된다. 신비 톱다! 

Gitosis 를설 치하기 가쉽지 는않지 만그렇 다고어 렵지도 않다. Gitosis 는리 눅스에 설치하 는것이 가 
장 쉽다. 여 기서는 Ubuntu 8. 1 0 서버를 사용 한다. 

Gitosis 는 Python 이 필 요하기 때문에 먼저 Python setuptools 패 키지를 설 치해야 한다. Ubuntu 
에 서는아 래와같 이설치 한다: 



$ apt-get install python— setuptools 



그리고 Gitosis 프 로젝트 사이 트에서 Gitosis 를 Clone 한 후 설치 한다: 



$ git clone https://github.com/tv42/gitosis.git 
$ cd gitosis 

$ sudo python setup. py install 




GitOSis 가 설 치되면 GitOSis 는 겨장소 디텍 토리로 /home/git 를 사용 하려고 한다. 이대로 사 용해도 괜 
찮 지만， 우리의 저 장소는 이미 / 0pt /gi t 에 있다. 다시 설 정하지 말고 아래와 같이 간 단하게 심볼릭 링크 

를만 들자: 
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$ In -s /opt/git /home/git/repositories 



Gitosis 가 키들을 관리할 것이기 때문에 현재 파 일은삭 제하고 다시 추 가해야 한다. 이제 부터는 Gitosis 
가 authorized—keys 파일을 자 동으로 관리할 것 이다. authorized— keys 파일을 백업해 두자: 



$ mv /home/git/. ssh/authorized_keys /home/git/ . ssh/ak . bak 



그리고 git 계정의 쉘을 git-shell 로 변경했 었다면 원 래대로 복 원해야 한다. Gitosis 가 대신 이 일을 말 
아줄 것이기 때문에 복원 해도사 람들은 여견히 로그 인할수 없다. /etc/passwd 파일의 [ ᅡ음 줄을: 



git :x: 1000： 1 000 ： ： /home/git ： /usr/bin/git— shell 



아 래와같 이변경 한다: 



git :x: 1000： 1 000 ： ： /home/git ： /bin/sh 




이제 GitOSis 를 초기화 할차례 다. gitosis-init 명렁을 공개키 와함깨 실행 한다. 만약공 개키가 서버에 
없으면 공개키 를서버 로복사 해와야 한다: 



$ s 니 do -H -u git gitosis-init < Atmp/id— dsa.p 니 b 

Initialized empty Git repository in /opt/git/gitosis-admin.git/ 

Reinitialized existing Git repository in /opt/git/gitosis-admin.git/ 




이 명 렁으로 등 록하는 키의 사 용자는 Gitosis 를 제 어하는 파 일들이 있는 Gitosis 설정 저 장소를 수정 

할 수 있게 된다. 그리고 수 동으로 post— update 스크 립트에 실행 권한을 부여 한다: 



$ sudo chmod 755 /opt/git/gitosis-admin. git/hooks/post-update 



모든 준비가 끝 났다. 설정이 잘 됐으면 추가한 공 개키의 사 용자로 SSH 서버에 집 속했을 때 아래와 같 
은 메시지 를보게 된다: 

$ ssh git@gitserver 

PTY allocation request failed on channel 0 

ERROR ： gitosis . serve . main ： Need SSH— ORIGINAL—COMMAND in environment, 
fatal ： unrecognized command 'gitosis-serve schacon@quaternion 1 
Connection to gitserver closed. 
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이것 은접속 을시도 한사용 자가누 구인지 식별할 수는있 지만， Git 명렁이 아 니어서 거 절한다 는뜻이 
다. 그러니 까실제 Git 명렁 어를실 행시켜 보자. Gitosis 제어저 장소를 Clone 한다: 

# on your local computer 

$ git clone git@gitserver:gitosis-admin.git 



gitosis-admin 이라는 디렉토 리가생 긴다. 디 텍토리 내용은 크게두 가지로 나늘수 있다: 

$ cd gitosis— admin 

$ find . 

. /gitosis. conf 

./keydir 

./keydir/scott.pub 



gitoiss.conf 파 일은사 용자, 저 장소, 권 한등을 명 시하는 설 정파일 이다. keydir 디텍토 리에는 저장소 
에 접 근할수 있는사 용자의 공개키 가저장 된다. 사용자 마다공 개키가 하나씩 있고 이 공 개키로 서버에 
집근 한다. 이 예제 에서는 scott. pub 이지만 keydir 안에 있는 파일의 이름은 사용자 마다다 르다. 파일 이 
름은 gitosis-init 스크 립트로 공 개키를 추가할 때 결정 되는데 공개키 끝 부분에 있는 이름이 사용 된다. 
이제 gitosis. conf 파일 을열어 보자. 지금막 Clone 한 gitosis-admin 프로 젝트에 대 한정보 만들어 있 
다: 

$ cat gitosis. conf 
[gitosis] 

[group gitosis-admin] 
members = scott 
writable = gitosis-admin 



SCOtt 이 라는사 용자는 GitOSis 를 초기화 할때사 용한공 개키의 사용자 이다. 이사 용자만 gitosis— admin 
프로젝 트에집 근할수 있다. 

이제 프로 젝트를 새로 추가해 보자. mobile 단락을 추 가하고 그 프로 젝트에 속한 개 발자나 프로 젝트에 
접근해 야하는 사용자 를추가 한다. 현재는 SCOtt 이외에 다른사 용자가 없으니 scott 만추가 한다. 그리 
고 iphone— project 프로 젝트를 새로 추가 한다: 



[group mobile] 

writable = iphone_project 

members = scott 




gitosis-admin 프로젝 트를수 정하면 커 밋하고 서버에 Push 해야 수정한 설정이 격용 된다: 
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$ git commit —am 'add iphone— project and mobile gro 니 p' 
[master 8962da8] add iphone— project and mobile group 
1 file changed, 4 insertions(+) 
$ git push origin master 
Counting objects: 5, done. 
Compressing objects: 100% (3/3), done. 
Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done. 
Total 3 (delta 0), reused 0 (delta 0) 
To git@gitserver:gitosis-admin.git 
fb27aec. .8962da8 master -> master 



로컬에 있는 iphone—project 프로 젝트에 이 서버를 리모트 저 장소로 추 가하고 Push 하면 서버에 새로 

운 저 장소가 추가 된다. 서버에 프로 젝트를 새로 만들 때 이제는 수 동으로 Bare 저 장소를 만들 필요가 
없다. 처음 Push 할 때 Gitosis 가 알아서 생성해 준다: 

$ git remote add origin git@gitserver:iphone_project .git 
$ git push origin master 

Initialized empty Git repository in /opt/git/iphone_project.git/ 
Counting objects: 3, done. 



Writing objects: 100% (3/3)， 230 bytes I 0 bytes/s, done. Total 3 (delta 0)， 
reused 0 (delta 0) To git@gitserver:iphone_project.git * [new branch] master 
-) master 

Gitosis 를 이용할 때에는 저장소 경로를 명시할 필요도 없고 사용할 수도 없다. 단지 콜론 뒤에 프로젝 
트 이름만 격어도 Gitosis 가 알아서 찾아 준다. 

동료와 이 프로 젝트를 공유 하려면 동료의 공 개키도 모두 추 가해야 한다. ~/ . ssh/authorized_keys 파일 
에 수 동으로 추 가하는 게 아니라 keydir 디롁 토리에 하나의 공 개키를 하나의 파일로 추가 한다. 이 공개 

키의 파일 이름이 gitosis. conf 파 일에서 사용하 는사용 자이름 을결정 한다. Johnjosie, Jessica 의공 
개키를 추가해 보자: 



$ cp /tmp/icLrsa.john.pub keydir/john.pub 
$ cp /tmp/ id_rsa . j osie . pub keydir/josie.pub 
$ cp /tmp/ id_rsa . j essica . pub keydir/jessica.p 니 b 




이 세 사람을 모두 mobile 팀으로 추 가하여 iphone_pr 0 ject 에 대한 읽기， 쓰기를 허용 한다: 



[group mobile] 

members = scott john josie jessica 
writable = iphone_project 



90 



Scott Chacon Pro Git 



4.8 절 Gitolite 



이 파일을 커 밋하고 Push 하고 나면 네 명 모두 iphone— project 를 읽고 쏠 수 있게 된다. 

Gitosis 의 집 근제어 방법은 매우 단순 하다. 만약 이 프로 젝트에 대해서 John 은 읽기만 가능 하도록 설 

정하려 면아래 와같이 한다: 

[group mobile] 

members = scott josie jessica 
writable = iphone_project 

[group mobile— ro] 

members = john 

readonly = iphone_project 

이제 John 은 프로 젝트를 Clone 하거나 Fetch 할 수는 있 지만， 프로 젝트에 Push 할 수는 없다. 다양한 
사 용자와 프로 젝트가 있어도 필요한 만큼 그룹을 만들어 사 용하면 된다. 그리고 members 항목에 사 
용자 대신 그 룹명을 사용할 수도 있다. 그룹명 앞에 @ 를붙 이면그 그룹의 사 용차를 그대로 상속 한다: 

[group mobile— committers] 
members = scott josie jessica 

[group mobile] 

members = ©mobile— committers 
writable = iphone— project 

[group mobile— 2] 

members = ©mobile— committers john 
writable = another— iphone— project 

[gitosis] 질에 loglevel=DEBUG 라고 격으면 문제가 생겼을 때 해결 하는데 도움이 된다. 그리고 설정 

이꼬여 버려서 Push 할 수없게 되면 서버에 있는파 일을수 동으로 고처도 된다. Gitosis 는 /home/ 
git/. gitosis. conf 파일의 정보 를읽기 때문에 이 파 일을고 친다. gitosis .conf 는 Push 할 때그우 ᅵ치로 
복 사되기 때문에 수 동으로 고친 파일은 gitosis-admin 프로 젝트가 다음에 Push 될 때까지 유지 된다. 

4.8 Gitolite 

이 질 에서는 Gitolite 가 뭐고 기본 적으로 어떻게 설 치하는 지를 살펴 본다. 물론 Gitolite 에 들어 있는 
Gitolite 문서는 양이 많아서 이 질에서 모두 다룰 수 없다. Gitolite 는 계속 진 화하고 있기 때문에 이 책 
의 내용과 다를 수 있다. 최신 내용은 여 기에서 확 인해야 한다. 

Gitolite 은 간단히 말해 Git 위에서 운 영하는 권한 제어 (Authorization) 도 구다. 사용자 인증 (Au- 
thentication) 은 sshd 오ᅡ httpd 를 사용 한다. 집속한 접 속하는 사 용자가 누 구인지 가 려내는 것이 인증 
(Authentication) 이고 리 소스에 대한 접근 권한을 가 려내는 일은 권한 제어 (Authorization) 이다. 
Gitdite 는 저장 소뿐만 아니라 저 장소의 브 탠치나 태 그에도 권한을 명시할 수 있다. 즉, 어떤 사람은 
refs (브 랜치나 태그) 에 Push 할 수 있고 어떤 사람은 할 수 없게 하는 것이 가능 하다. 
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4.8.1 설 치하기 

별도 문서를 읽지 않아도 유닉스 계정만 하나 있으면 Gitolite 를 쉽게 설치할 수 있다. 이 글 은여러 가 
지 리눅 스들과 솔 라리스 1 0 에서 테 스트를 마 쳤다. Git, Perl, OpenSSH 가호 환되는 SSH 서버가 설치 
돼 있으면 root 권한도 필요 없다. 앞서 사 용했던 gitserver 라는 서버와 그 서버에 git 계정을 만들어 사 
용 한다. 

Gitdite 는 보통의 서버 소 프트웨 어와는 달리 SSH 를 통해서 집근 한다. 서버의 모든 계정은 근 본격으 
로 "Gitolite 호스트 "가 될 수 있다. 이 책 에서는 가장 간단한 설치 방 법으로 설명 한다. 자세 한설명 문 
서는 Gitolite 의 문서를 참고 한다. 

먼저 서버에 git 계정을 만들고 git 계 정으로 로그인 한다. 사 용자의 SSH 공개키 (ssh-keygen 으로 생 
성한 SSH 공 개키는 7 1 본 적으로 ~/ . ssh/id_rsa . pub 에 위 치함) 를 복 사하여 〈이름 > . pub 파일로 저 장한다 
(이 책의 예제 에서는 scott.pub 로 저장 ). 그리고 다음과 같은 명령을 실행 한다: 

$ git clone git://github.com/sitaramc/gitolite 
$ gitolite/install -In 

# $H0ME/bin 가 이미 $PATH 에 등록돼 있다고 가정 
$ gitolite setup — pk $HOME/scott.pub 



마지막 명령은 gitolite-admin 라는새 Git 저 장소를 서버에 만 든다. 

다시 작 업하던 환경 으로돌 아가서 git clone git@gitserver:gitolite-admin 명 령으로 서버의 저 장소를 

Clone 했을 때 문 제없이 Clone 되면 Gitolite 가 정상 격으로 설치된 것 이다. 이 gitoiite-admin 저장소 
의 내용을 수 정하고 Push 하여 Gitolite 을 설 치를마 치도록 한다. 

4.8.2 자 신에게 맞게설 치하기 

보통은 기본설 정으로 빠르게 설 치하는 것으로 충분하 지만, 자 신에게 맞게 고처서 설치할 수 있다. 일부 
설정은 주 석이잘 달 려있는 rc 파일을 간단히 고처서 쏠 수 있 지만， 자세한 설정을 위 해서는 Gitolite 가 
제 공하는 문서를 살펴 보도록 한다. 

4.8.3 설정 파일과 집근제 어규칙 

설 치가완 료되면 홈 디텍 토리에 Clone 한 gitolite-admin 디롁 토리로 이 동해서 어떤 것들이 있는지 한 
번 살펴 보자: 

$ cd -/gitolite-admin/ 
$ Is 

conf/ keydir/ 

$ find conf keydir -type f 

conf /gitolite. conf 

keydir/scott.pub 

$ cat conf /gitolite. conf 

repo gitolite-admin 

RW+ = scott 
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repo testing 

RW+ = @all 



gitolite setup 명렁을 실 행했을 때 주었던 공개키 파일의 이름인 scott 은 gitolite— admin 저 장소에 대 
한 읽기와 쓰기 권한을 갖도록 공 개키가 등록돼 있다. 

사 용자를 새로 추가 하기도 쉽다. "alice" 라는 사 용자를 새로 등록 하려면 우선 등록할 사람의 공개키 파 

일을 얻어서 alice. pub 라는 이 름으로 gitolite-acMn 디 롁토리 아래에 keydir 디롁 토리에 저장 한다. 새 
로 추가한 이 파일을 Add 하고 커밋한 후 Push 를 하면 alice 라는 사 용자가 등록된 것 이다. 
Gitolite 의 설정 파일인 conf /example. conf 에 대한 내용은 Gitolite 문서에 설명이 잘되어 있다. 이 책 
에서는 주요 일부 설정에 대 해서만 간단히 살펴 본다. 

저 장소의 사용자 그룹을 쉽게 만들 수 있다. 이 그룹은 매크로 와비숫 하다. 그룹을 만들 때는 그 그룹이 
프로 젝트의 그 룹인지 사 용자의 그 룹인지 구 분하지 않지만 사용할 때에는 다 르다. 



@oss_repos 


= linux perl rakudo git gitolite 


@secret_repos 


= fenestra pear 


©admins 


= scott 


©interns 


= ashok 


©engineers 


= sitaram dilbert wally alice 


©staff 


= ©admins ©engineers ©interns 



그리고 ref 단위로 권한을 제어 한다. 다음 예제를 보자. 인턴 (interns) 은 int 브 랜치만 Push 할 수 있 
고 engineers 는 eng- 로 시 작하는 브 탠치와 rc 뒤에 숫차가 붙는 태그만 Push 할 수 있다. 그리고 관리 
자는 모든 ref 에 무엇 이든지 (되돌 리기도 포 함됨) 할 수 있다. 



repo @oss_repos 




RW int$ 


= ©interns 


RW eng— 


= ©engineers 


RW refs/tags/rc[0-9] 


= ©engineers 


RW+ 


= ©admins 



나 rw+ 뒤에 나오는 표 현식은 정규 표현식 (regex) 이고 Push 하는 ref 이름의 패턴을 의미 한다. 그래 
서 우리는 refex 라고 부 른다. 물론 refex 는 여기에 보여준 것보다 휠씬 더 강력 하다. 하 지만, 펄의 정규 
표 현식에 익 숙하지 않은 독자도 있으니 여기 서는무 리하지 않 았다. 

그리고 이미 예상했 겠지만 Gitolite 는 refs/heads/ 라고 시 작하지 않는 refex 에 대 해서는 암묵 격으로 

ref s/heads/ 가 생략된 것으로 판단 한다. 

특정 저 장소에 사 용하는 규칙을 한 곳에 모아 놓지 않아도 괜 찮다. 위에 보여준 oss— repos 저장소 설정 
과 다른 저장소 설정이 마구 섞여 있어도 괜 찮다. 아래와 같이 목적이 분 명하고 제 한격인 규칙을 아무 데 
나추 가해도 좋다: 
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repo gitolite 
RW+ 


= sitaram 





이 규칙은 gitolite 저 장소를 위해 지금 막 추가한 규칙 이다. 

이제는 집 근제어 규칙이 실제로 어떻게 적용 되는지 설명 한다. 이 제부터 그 내용을 살펴 보자. 
Gitdite 는 집근 제어를 두 단게로 한다. 첫 단계가 저장소 단 게인데 접 근하는 저 장소의 ref 중에서 하 
나라도 읽고 쏠 수 있으면 실제로 그 저장소 견부에 대해 읽기, 쓰기 권한이 있는 것 이다. 
두 번째 단계는 브 탠치나 태그 단위로 제 어하는 것으로 오직 "쓰 기" 집근만 제어할 수 있다. 어느 사용 
자 가특정 ref 이 름으로 집근을 시 도하면 (#4 + 같은) 설정 파일에 정의된 순 서대로 집근 제어 규 칙이적 
용 된다. 그 순 서대로 사용자 이름과 ref 이름을 비교 하는데 ref 이름의 경우 단순히 문 자열을 비 교하는 
것이 아니라 정규 표현 식으로 비교 한다. 해 당되는 것을 찾으면 정상 적으로 Push 되지만 찾지 못하면 거 
결 된다. 

4.8.4 "deny" 규칙을 꼼 꼼하게 제 어하기 

지금 까지는 R， RW, rw+ 권한에 대 해서만 다 뤘다. Gitolite 는 "deny" 규칙을 위해서 - 권한도 지원 한다. 
이 것으로 복 잡도를 낯출 수 있다. -로 거절도 할 수있기 때문에 규칙의 순서 가중요 하다. 
다시 말해서 engineers 가 master 와 integ 브탠치 이외의 모든 브 탠치를 되돌릴 수 있게 하고 싶으면 
아래 와같이 한다: 



RW master integ 


= ©engineers 


― master integ 


= ©engineers 


RW+ 


= ©engineers 



즉, 집 근제어 규칙을 순 서대로 찾기 때문에 순 서대로 정 의해야 한다. 첫 번째 규칙은 master 나 integ 
브 탠치에 대해서 읽기， 쓰기만 허 용하고 되돌 리기는 허 용하지 않 는다. master 나 integ 브 랜치를 되돌 
리는 Push 는 첫 번째 규칙에 어 긋나기 때문에 바로 두 번째 규 칙으로 님어 간다. 그리고 거기서 거절된 
다. master 나 integ 브랜치 이외 다른 ref 에 대한 Push 는 첫 번째 규칙과 두번째 규 칙에는 만 족하지 
않고 마지막 규칙으 로허용 된다. 

4.8.5 파일 단위로 Push 를 제 어하기 

브랜치 단위로 Push 를 제어할 수 있지만 수정된 파일 단 위로도 제어할 수 있다. 예를 들어 Makefile 을 
보자. Makefile 파일에 의 존하는 파일은 매우 많고 보통 꼼 꼼하게 수 정하지 않으면 문제가 생 긴다. 그 
래서 아무나 Makefile 을 수 정하게 둘 수 없다. 그러면 아래와 같이 설정 한다: 



repo foo 

RW = @junior_devs ©senior— devs 

- VREF/NAME/Makefile = @j unior_devs 
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예전 버전의 Gitolite 에서 버견 을올리 려는사 용자는 설정이 많이 달라진 것 을알게 될 것 이다. Gitolite 
의 버견 업가이 드를필 히참고 하자. 

4.8.6 Perswial 브탠치 

Gitolite 는 또 "Personal 브랜치 "라고 부르는 기능을 지원 한다. 이 기능은 실제로 "Personal 브탠치 

네임스 페이스 "라 고부르 는것이 더 격결 하다. 이 기 능은기 업에서 매 우유용 하다. 

Git 을 사 용하다 보면 코드를 공유 하려고 "Pull 해주 세요" 라고 말해야 하는 일이 차주 생 긴다. 그런데 

기업 에서는 인 증하지 않은 집근을 결대 허용 하지도 않는 데다가 아예 다른 사람의 컴 퓨터에 집근할 수 

없다. 그 래서공 유하려 면중앙 서버에 Push 하 고나서 Pull 해야 한다고 다른사 람에게 말 해야만 한다. 

중앙 집중식 VCS 에서 이렇게 마구사 용하면 브탠치 이름이 충돌할 확를이 높다. 그때마 다관리 자는추 

가 로권한 을관리 해줘야 하기때 문에관 리자의 노력이 쏠데없 이낭비 된다. 

Gitdite 는 모든 개 발자가 "personal "이나 "scratch" 네 임스페 이스를 가질 수 있도록 허용 한다. 이 

네 임스페 이스는 refs/personal/<devname>/* 라고 표현 한다. 자세한 내용은 Gitolite 문서를 참고 한다. 

4.8.7 "와 일드 카드" 저장소 

Gitolite 는 펄 정 규표현 식으로 저장소 이름을 표 현하기 때문에 와일드 카드를 사용할 수 있다. 그래서 

assignments/s[0-9] [0-9]/a[0-9] [0-9] 같은정 규표현 식을사 용할수 있다. 사용 자가새 로운저 장소를 
만들 수 있는 새로운 권한 모드인 C 모드를 사용할 수도 있다. 저 장소를 새로 만든 사람 에게는 자 동으로 
집근 권한이 부여 된다. 다 른사용 자에게 접근 권한을 주려면 R 또는 RW 권한 을설정 한다. 다시 한번 말하 
지만 문서에 모든 내용이 다 있 으으로 꼭 보 기를바 란다. 

4.8.8 그밖의 기능들 

마지 막으로 알고 있으면 유용한 것들이 있다. Gitolite 에는 많은 기능이 있고 자세한 내용은 "Faq， Tip, 
등등" 의 다른 문서에 잘 설명돼 있다. 

로깅: 누군가 성공 격으로 집 근하면 Gitolite 는 무조건 로그를 남 긴다. 관리 자가한 눈파는 사이에 되돌 

리기 (RW+) 권한을 가진 망 나니가 master 브 랜치를 날 려버릴 수 있다. 이 경우 로그 파일이 구원해 준다. 
이 로그 파일을 참 고하여 버려진 SHA 를 빠르고 쉽게 찾을 수 있다. 

접근 권한 보여 주기: 만약 어떤 서 버에서 작업을 시작 하려고 할 때 필요한 것이 무엇 일까? Gitolite 는 
해당 서버에 대해 집근할 수 있는 저 장소가 무엇 인지, 어떤 권한을 가 졌는지 보여 준다: 



hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1 .7.4.4 


R 


anu-wsd 


R 


entrans 


R W 


git-notes 


R W 


gitolite 


R W 


git 이 ite— admin 


R 


indic_web_input 


R 


shreelipi— converter 



권한 위임: 조직 규모가 크면 저 장소에 대한 책임을 여러 사람이 나눠 가지는 게 좋다. 여러 사람이 각 
자 말은바 를관리 하도록 한다. 그래서 주요관 리자의 업무 가줄어 들기에 병목 현상이 격어 진다. 이 기 
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능에 대 해서는 doc/ 디텍 토리에 포함된 Gitolite 문서를 참고 하라. 
미 러링: Gitdite 의 미러 는여러 개 만들 수있어 서주서 버가다 운돼도 변 경하면 된다. 

4.9 Git 데몬 

공개된 프로 젝트는 누가 읽기 집근을 시도 하는지 알 필요가 없다. 그래서 HTTP 프로토 클을사 용하거 
나 Git 프로 토콜을 사 용해야 한다. Git 프로 토콜이 HTTP 프로토 콜보다 효율 격이기 때문에 속도가 빠 
르다. 따라서 사 용자의 시간을 결약해 준다. 

다시 강조하 지만， 이것은 불특정 다 수에게 읽기 접근 을허용 할때에 만쏠만 하다. 만약 서버가 외부에 
그낭 노출돼 있으면 우선 방화 벽으로 보 호하고 프로 젝트만 외 부에서 접근할 수 있게 만 든다. 서버를 방 
화 벽으로 보 호하고 있으면 CI 서버나 빌드 서 버같은 컴 퓨터나 사람이 읽기 집근이 가능 하도록 설정한 
다. 모두 SSH 키를 일일이 추 가하고 싶지 않을 때 이 방법 을사용 한다. 
어쨌든 Git 프로 토콜은 상대 격으로 설 치하기 쉽다. 그낭 데돈을 실행 한다: 



git daemon ―— reuseaddr ―— base-path=/opt/git/ /opt/git/ 



-reuseaddr 는 서버가 기존의 연결이 타임 아웃될 때까지 기 다리지 말고바 로재시 작하게 하는 옵션이 
다. -base-path 옵션을 사 용하면 사 람들이 프로 젝트를 Clone 할 때 전체 경로를 사 용하지 않아도 된다. 
그 리고마 지막에 있는 경로는 노출할 저 장소의 우ᅵ 치다. 마지 막으로 방화 벽을사 용하고 있으면 941 8 포 

트를 열어서 지금 작 업하는 서버의 숨통을 틔워 준다. 

운영 체제에 따라 Git 데돈을 실행 시키는 방법은 다 르다. 우분투 에서는 Upstart 스크 립트를 사용 한다. 
아래와 같이파 일을만 들고: 



/etc/event .d/local-git-daemon 



다음 의내용 을입력 한다: 

start on startup 
stop on shutdown 
exec /usr/bin/git daemon \ 

―— 니 ser=git ―— group=git \ 

―— reuseaddr \ 

―— base-path=/opt/git/ \ 

/opt/git/ 
respawn 



저 장소를 읽을 수만 있는사 용자로 데몬을 실 행시길 것을 보안을 위해 강 력하게 권고 한다. git-ro 라는 
계정 을새로 만들고 그 계 정으로 데몬을 실행시 킨다. 여기 에서는 쉽게 설명 하려고 그낭 Gitosis 를 실행 
했던 git 계 정으로 실행시 킨다. 

서버가 재 시작할 때 Git 데몬이 자 동으로 실 행되고 데몬이 죽어도 자 동으로 재시작 된다. 서버는 놔두 
고 Git 데돈 만재시 작할수 있다: 
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initctl start local-git-daemon 



다른 시스템 에서는 sysvinit 시 스템의 xinetd 스크 립트를 사용 하거나 자 신만의 방 법으로 해야 한다. 

Git 데몬을 통해서 아무나 읽을 수 있다는 것을 Gitosis 서버에 알려 주어야 한다. Git 데 몬으로 읽기 집 
근을 허 용하는 저 장소가 무 엇인지 설정에 추 가해야 한다. 만약 iphone— project 에 Git 프로 토클을 허용 
했다면 아래와 같은 것을 gitosis .conf 파일의 하단에 추가 한다: 

[repo iphone_project] 
daemon = yes 



차 례대로 커밋과 Push 하고 나면 지금 실행 중인 데몬이 941 8 포트로 집근 하는사 람에게 서비 스하기 
시작 한다. 

Gitosis 없이도 Git 데몬을 설치할 수 있지만 그 러려면 서비스 하고자 하는 프로젝 트마다 아래와 같이 

git— daemon— export— ok 파일을 넣어 주어야 한다: 

$ cd /path/to/project .git 
$ touch git— daemon— export-ok 

이 파일이 있으면 Git 데온은 인증 없이 프로 젝트를 노 출하는 것으로 판단 한다. 

또한, Gitweb 으로 노 출하는 프로 젝트도 Gitosis 로 제어할 수 있다. 먼저 /etc/gitweb.conf 파일에 아 

래와 같은내 용을추 가해야 한다: 

$projects_list = "/home/git/gitosis/projects.list" ； 
$projectroot = "/home/git/repositories"; 
$export_ok = "git-daemon-export-ok" ； 
@g i t_ba se_ur 1_1 i st = ( 'git://gitserver' )； 



Gitosis 설정 파일에 gitweb 설정을 넣거나 빼면 사 용자는 GitWeb 을 통해 프로 젝트를 볼수도 있고못 
볼수도 있다. 

[repo iphone_project] 
daemon = yes 
gitweb = yes 



이제 이것을 커 밋하고 Push 하면 GitWeb 을 통해 iphone— project 를 볼 수 있다. 
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Git 서버를 설 치하는 등의 일을 하고 싶지 않으면 견문 호스팅 사 이트를 이 용하면 된다. 호스팅 사이트 
는 몇가지 장점이 있다. 설정이 쉬워서 바로 프로젝 트를시 작할수 있을뿐 만아니 라직집 서버 를관리 
하고 모니터 링하지 않아도 된다. 내부 격으로 Git 서버를 직접 설 치하고 운 영하고 있어도 오 픈소스 프로 
젝트는 호스팅 사 이트를 이 용하는 것이 좋다. 이렇게 하면 보통 오 픈소스 커 뮤니티 로부터 좀 더 쉽게 도 
움 받을수 있다. 

요즘은 이용할 수 있는 호스팅 사이 트들이 많다. 각각 장 단점이 있기 때문에 다음 페이 지에서 최신 정 
보를 확인해 보자: 



https ： I /git .wiki. kernel . org/index . php/GitHosting 



이 결에서 전부설 명할수 는없고 (필 자는저 회사 중한군 데에서 일 한다) GitHub 에 계정 과프로 젝트를 
만드 는방법 을설명 한다. 

GitHub 은 가장 큰 오 픈소스 Git 호스팅 사이 트이고 공개 (Public) 프로 젝트와 비공개 (Private) 프로 
젝트에 대한 호스팅 서 비스를 제공하 는보기 드 문사이 트다. 그래서 상업용 비공개 코드 와공개 코드를 
같 은곳에 둘 수 있다. 실제로 이 책도 GitHub 에서 비 공개로 작성 했다. 

4.10.1 GitHub 

GitHub 는 프 로젝트 네 임스페 이스가 다른 코드 호스팅 사이 트들과 다 르다. GitHub 는 프로 젝트가 아 
니라 사용자 가중심 이다. GitHub 에 grit 프 로젝트 를호스 팅하고 싶으면 github.com/ grit 이 아니라 
github.com/schacon/grit 으로 집 속해야 한다. 그리고 처음 프로 젝트를 시작한 사람이 그 프로 젝트를 잊 
어 버려도 누구나 프로 젝트를 이어갈 수 있다. 프 로젝트 주 저장 소라고 해서 특 별한게 아 니다. 
GitHub 은 이윤을 목 적으로 하는 회 사이기 때문에 비공개 저 장소를 만 들려면 돈을 내야 한다. 하 지만， 
누구나 손쉽게 무료 계정을 만들어 오 픈소스 프로 젝트를 시작할 수 있다. 어떻게 사용 하는지 간 락하게 
설명 한다. 



4.10.2 게정설 정하기 

먼저 무료 게정을 하나만 든다. 가격 정책에 대해 알 려주며 가입을 시작할 수있는 https://github.com/ 
pricing 에 방 문하여 "Sign up" 버튼 을클릭 한다. 그러면 가입 페 이지로 이동 한다. 



eithub ~&> 



Choose the plan that's right for you. 

Pma plana m MM monMy and can t» ucVKtsaamngrBlMi^wTTviaWcl ■! any Inw mMwuI pand^ 

Op«n Sourc* 



UNImlWd f\K -- Repos/Ufcs 

300 MB Oi»kScwc* ― 



그림 4.2: GitHub 가격 정책 페이지 



아직 등 록되지 않은 사용자 이름을 입 력하고 e-mail 주소와 암호를 입 력한다 (그림 4-3). 

그리고 SSH 공 개키가 있으면 바로 등록 한다. SSH 키를 만드는 방법은 "바로 설정 하기" 절에서 이 

미 설명 했다. 그 공개키 파일의 내 용을복 사해서 SSH 공개키 입력 박스에 붙여 넣 는다. "explain ssh 
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Sign up 



그림 4.3: GitHub 가입폼 

keys" 링 크를클 릭하면 key 를생 성하는 방법을 자세히 설명해 준다. 주요 운영체 제에서 하는 방법이 모 
두 설명돼 있다. "I agree, sign me up" 버튼을 클 릭하면 자 신만의 대 쉬보드 페 이지가 나타 난다. 



eithub —<^> 



News Feed 



Your RepOSit0rtM(CfMHarwwan«) 



그림 4.4: GitHub 사 용자대 쉬보드 

그리 고저장 소를만 들자. 
4.10.3 저장소 만들기 

Your Repositories 옆에 있는 "create a new one" 링크를 클 릭하면 저 장소를 만드는 입력 폼을 볼 수 
있다 (그림 4-5). 



Create a New Repository 

Ctmm * naw mpty npoMcry Me »Mf> you e*n putfi vaut local raea 

HOTM: «>B>MnMnd p 베 ■ cnp»«* * upoMDi'f tit • Mrxdy f ciliil on QaK*. run you tfwJd Wf* ■ mmd 
Ptotta Mill 

iphona proiM Uy out moM* grau(t 




0 AfjOm Mn< now DoJ »uHM npeW 



그림 4.5: GitHub 의 저장소 를생성 하는폼 

이 폼에 프 로젝트 이름과 프 로젝트 설명을 적 는다. 다 적은 후에 "Create Repository" 버튼을 클릭하 
면 GitHub 에저 장소 가생 긴다. 

이 저장 소에는 아직 코드가 없어서 GitHub 은 프로 젝트를 새로 만드는 방법， 이 미있는 Git 프로 젝트를 
Push 하는 법, 공개된 Subversion 겨장 소에서 프로 젝트를 가 겨오는 (Import) 방법 등을 보여 준다. 
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github 



MMInguaw MMM', 



/ IphOlM JKOi*d ᅵ j_JSL' ᅵ - yw M KW . 
VbwCkmURL urn 1»|Mii»>Mimin|MtJI , 



그림 4.6: GitHub 프로책 트정보 



Global setup: 

DoNnlood and \nstoll Git 

git config --global user. email test#gi thub . cam 

Next iteps: 

akdir \phonc_project 

cd iphoo«_proj«t 

git init 

touch README 

git add README 

git ccMBit 'first comit' 

git rewote add origin 9it9github.con:testingu5er/iphone_project.{ 
git push origin moster 

Existing Git Repo? 

cd cxisting_git_repo 

git reaote odd origin git9github.can:testinguser/iphone_project.( 
git push origin noster 

Importing a SVN Repo? 



When you're done: 



그림 4.7: 새 저장 소를위 한사용 설명서 



여기 설 명하는 내용 은이미 우리가 배 웠다. 프로 젝트가 없을 때는 아래와 같이 프로 젝트를 초기화 한다: 



$ git init 
$ git add . 

$ git commit -m ' initial commit 1 



만약 이미 로컬에 Git 저 장소가 있으면 GitHub 저 장소를 리모트 저 장소로 - 
Push 한다: 



투하고 master 브 탠치』 



$ git remote add origin git@GitHub . com ： testinguser/ iphone_proj ect . git 
$ git push origin master 



이제 프로 젝트가 GitHub 에서 서비 스되니 공 유하고 싶은 사 람에게 URL 을 알려 주면 된다. URL 은 이 
다. 그리고 이 저 장소의 정보를 잘 살 펴보면 Git URL 이 두 개라는 것을 발견할 수 있다. 



testinguser /iphone_project C> «m ) ( • unwaich ) 

iphono project for our mobile group odil 
Homepage: Click to edit ecit 

Public Ckxie URL: git i//github cofWtesting user/iphone project.git 
Your Clone URL: git @ gitfiub.com nesting user^hone proj&ctgit £ 



그림 4.8: 프로 책트의 공개 URL 과 비공개 URL 



Public clone url 은 말 그대로 누구나 프로 젝트를 Clone 할 수 있도록 모 두에게 읽기 전 용으로 공개하 
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는 것 이다. 이 URL 을 다른 사람에 알려주 거나웹 사이트 같은데 공 개하는 것 을부담 스러워 하지 않아도 
된다. 

Your Clone URL 은 읽고쏠 수있는 SSH 기반 URL 이다. 사 용자계 정에등 록한공 개키와 한짝인 개인키 
로만 집속할 수 있다. 다른 사 용자로 이 프로 젝트에 방 문하면 이 URL 은 볼 수없고 공개 URL 만 볼수있 
다. 



4. 1 0.4 Subversion 으 로부터 코드 가 져오기 (Import) 

GitHub 은 공개 중인 Subversion 프로 젝트를 Git 프로 젝트로 만들어 준다. 사용 설명서 하단에 있는 
"Subversion 에서 Import 하기" 링 크를클 릭하면 임포트 폼을볼 수있고 거기에 Subversion 프로젝 
트의 URL 을 넣는다 (그림 4-9). 



Import a Subversion Repository 

RMd B#for， ProcMdlng 



SVNnipMlttyURL'!' 



그림 4.9: Subversion 프로 젝트를 Imp 이 t 하는 화면 

프 로젝트 가비표 준방식 을사용 하거나 규모가 너무크 고비공 개라면 이 기 능을사 용할수 없다. 7 장에 
서 수 동으로 임포 트하는 방법에 대해 좀 더 자세히 배 운다. 

4.10.5 동료추 가하기 

동료를 추가 하자. 먼겨 John 씨, Josie 씨, Jessica 씨를 모두 GitHub 에 가입 시키고 나서 그들을 동료 
로 추 가하고 저 장소에 Push 할 수 있는 권한을 준다. 

프로 젝트페 이지에 있는 Admin 버 튼을클 릭해서 관리 페이 지로이 동한다 (그림 4—10). 



testmgusef / IphoiM.. project 

PBbfcOawUW^tfiigt** 'ᅵ »B,,wi，i>,ii<ptwB ᅳ jw»ct»» B 




OmuoPtg*. OwM* PnHtct P^t 

RuCyOam (5 □ 






Repository Collaborators 






그림 4.10: GitHub 으ᅵ프 


로젝 트관리 페이지 



다른사 람에게 쓰기 권한을 주려면 "Add another collaborator" 링크 를클릭 한다. 그러면 텍스트 박 
스가 새로 나 타나는 데 거기에 사용차 이름을 입력 한다. 사용자 이름을 입 력하기 시^ ᅡ면 자 동으로 시 

스템에 존 재하는 사 용자를 찾아서 보여 준다. 원하는 사 용자를 찾으면 Add 버튼을 클 릭해서 그 사용자 
를동 료로만 든다. 

추가 한사람 은동료 목록박 스에서 모두 확인할 수있다 (그림 4-12). 

그리고 만약 다시 혼 자작업 하고싶 어지면 "revoke" 링 크를클 릭하여 쫓아 낸다. 쫓 겨나면 더는 Push 
할 수 없다. 또기존 프로 젝트에 등록된 동료를 그 룹으로 묶어 추가할 수도 있다. 
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Repository Coll&boralori 



「'해 ᅳ 



뻬 m 



그림 4.1 1 ： 프로 젝트에 동료 추 가하기 



Repository Collaborators 

■ schacon revoke 

duncanparkes revoke 
spearce revoke 

^^^^^^^^^^^J (Add) or done 



그림 4. 12: 프 로젝트 동료들 



4.10.6 내프 로젝트 

Subversion 에서 Import 했거나 로컬의 프로 젝트를 Push 하고 나면 프 로젝트 메인 페이지 가그림 
4-1 3 같이 바 뀐다. 

？ itnUD Horn* PiMwf ttd fltgmin RapeMortM BMg Ugn 

OvXulltOO»« MM* OtM* M 



9ovm Com** Hilnnr>n) OMMDMH0) Wla(l) QripM 



lestin^uwK / lphon«_pro|*et \^mmJ <MMmtO 








tMttUl CMMt 


tr， 




phone project 1 








^ t\aua%/ 1 tmn ᅳ •> 




(•wit [KhacwiJ 


- Inrt.pl l M 1 tmft a|B 


InttUl 


court, [KtaunJ 








bu(U/ 1 «»4 


tnltUt 




」 t"t.'。,w»"，y s ttg* «|0 






- iCilVi«CO«r»l»»r.rt» 1 doyi •«> 



















그림 4.13: GitHub 의 프 로잭트 메인 페이지 



사 람들이 이 프로 젝트에 방 문하면 이 페이지 가제일 처음보 인다. 이 페 이지는 S 가지 랩으 로구성 된다. 
Commits 랩은 지금 까지의 커밋을 git log 명령을 실 행시킨 것처럼 초ᅵ신 것부터 보여 준다. Network 
랩은 프로 젝트를 복제한 사 람들과 기여한 사 람들을 모두 보여 준다. Downloads 랩에는 바 이너리 파일 
이나 프로 젝트의 태그 버견을 압 축해서 울릴 수 있다. Wiki 랩은 프로 젝트에 대한 정보나 문서를 쓰는 
곳 이다. Graphs 랩은사 람들의 활동 을그림 과통계 로보여 준다. 메인 랩인 Source 랩 은프로 젝트의 
메인 디텍토 리를보 여주고 README 파일이 있으면 자 동으로 화면에 출력해 준다. 그리 고마지 막커밋 
내용 도함깨 보여 준다. 
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4.10.7 프 로젝트 Fork 

권한이 없는 프로 젝트에 참 여하고 싶으면 GitHub 는 프로 젝트를 Fork 하도록 권고 한다. 마침 매우 흥 
미롭게 보 이는프 로젝트 를발견 했다고 하자. 그프 로젝트 를조금 뜯어고 치려면 프 로젝트 페이지 상단 
에 있는 "fork" 버튼을 클릭 한다. 그러 면 GitHub 는 집속한 사 용자의 계 정으로 프로 젝트를 Fork 해 준 
다. 사 용자는 이 프로 젝트에 마 음대로 Push 할수 있다. 

굳이 Push 할 수 있도록 사 람들을 동료로 추 가하지 않아도 된다. 사 람들은 마음껏 프로 젝트를 Fork 하 
고 Push 할 수 있다. 그리고 원래 프로 젝트의 관 리자는 다른 사람의 프로 젝트를 리모트 겨 장소로 추가 
하고 그 작 업물을 가 져와서 Merge 한다. 

프로 젝트페 이지에 들 어가서 상단의 "fork" 버 튼을클 릭하여 프로젝 트를복 제한다 (그림 4-14) 그림 
4-1 4 의 예는 mojom bo/chronic 프 로젝트 페이 지이다 



github "n® w< 




그림 4.1 4: 어떤 저장 소든지 "fork" 버튼을 클 릭하면 Push 할 수 있는 저 장소를 얻을 수 있다 



릭하는 순간, 이 프 로젝트 를즉시 Fork 한다 (그림 4-15). 

schacon / chronic C* «m) C • unwami; 

Fork of mc^ombo^iroruc 

Chronic is a pure Ruby natural language date parser cz\: 
Homepage: http://chronic.rubyforge.org edit 

Public Clone URL: git ^/github. oom/schacon/chronic.git Q 
Your Clone URL: gK@gitfiub.com:schacon/ctironic.git £ 

그림 4.15: Fork 한프 로젝트 



4.10.8 GitHub 요약 

빨리 한번 견체를 ft 어보는 것이 중 요하기 때문에 여기 에서는 GitHub 에 대해 이 정 도로만 설명 했다. 
몇 분 만에 계정과 프로 젝트를 만들고 Push 까지 할 수 있다. GitHub 에 있는 개발자 커 뮤니티 규모는 
매우 크기 때문에 만약 GitHub 에 오픈 소스 프로 젝트를 만들면 다른 개발 자들이 당신의 프로 젝트를 복 
제하고 당신을 도울 것 이다. GitHub 는 Git 을 빨리 사용해 볼 수 있도록 큽 는다. 



4.11 요약 

리모트 저 장소를 만들고 다른 사람 과협업 하거나 작 업물을 공 개하는 방법 은여러 가 지다. 

서버를 직집 구 축하는 것은 할 일이 많은 데다가 방 화벽도 필요 하다. 그리고 이렇게 서버를 만들고 관리 

하는 일은 시간이 많이 든다. 호스팅 사 이트를 이 용하면 쉽게 시 작할수 있다. 하 지만, 코드를 타인의 서 

버에 보관해 야하기 때문에 사 용하지 않는조 직들이 많다. 

자신의 조 직에서 어떤 방 법으로 협업해 야할지 고민해 야하는 시점이 되 었다. 
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앞 장에서 다른 개 발자와 코드를 공 유하는 리모트 겨 장소를 만드는 법을 배 웠다. 로 컬에서 작 업하는 데 

필 요한기 본적인 명렁어 에는어 느정도 익숙해 졌다. 이제는 분산환 경에서 Git 이 제공하 는기능 을어떻 
게 효율 적으로 사용할 지를배 운다. 

이번 장 에서는 분산 환 경에서 Git 을 어떻게 사용할 수 있을지 살펴 본다. 프 로젝트 기여자 입장과 여러 
수정 사항을 취 합하는 관리자 입 장에서 두루 살펴 본다. 즉, 프 로젝트 기여자 또는 관리 자로서 작 업물을 
프로 젝트에 어떻게 포함시 길지와 수 많은 개 발자가 수행한 일을 취 합하고 프로 젝트를 운 영하는 방법을 
배 운다. 

5. 1 분산 환경 에서의 Workflow 

중앙 집중형 버전 관리 시스 템과는 달리 Git 은 분산형 이다. Git 의 구조가 휠썬 더 유 연하기 때문에 여러 
개 발자가 함께 작 업하는 방식을 더 다 양하게 구성할 수 있다. 중앙 집중형 버견 관리 시스 템에서 각 개발 
자는 증앙 저 장소를 중 심으로 하는 하나의 노드일 뿐 이다. 하 지만, Git 에서는 각 개 발자의 저장 소가하 
나의 노드 이기도 하고 중앙 저장소 같은 역할도 할 수 있다. 즉， 모든 개 발자는 다른 개 발자의 저 장소에 
일한 내용을 견송하 거나, 다른 개발 자들이 참여할 수 있도록 차신이 운 영하는 저장소 위치를 공개할 수 
도 있다. 이런 특징은 프로 젝트나 팀이 코드를 운영할 때 다양한 Workflow 을 만들 수 있도록 해 준다. 
이런 유 연성을 살려 저 장소를 운 영하는 S 가지 방식을 소개 한다. 각 방식의 장 단점을 살 펴보고 그 방식 
중 하나를 고르거 나여러 가지를 격질히 섞어 쓰면 된다. 

5.1.1 중앙 집중식 Workflow 

중앙 집중식 시스템 에서는 보통 중앙 집중식 협업 모델 이라는 한 가지 방 식밖에 없다. 중앙 저 장소는 딱 
하나 있고 변경 사항은 모두 이 중앙 저 장소에 집중 된다. 개 발자는 이 중앙 저 장소를 중 심으로 작 업한다 

(그림 5-1). 

중 앙집중 식에서 개발자 두명이 중앙저 장소를 Clone 하고 각자 수 정하는 상황을 생각해 보자. 한 개발 
자가 자신이 한 일을 커 밋하고 나서 아무 문제 없이 서버에 Push 한다. 그러면 다른 개 발자는 자신의 일 
을커 밋하고 Push 하기 견에 첫 번째 개 발자가 한일을 먼저 Merge 해야 한다. Merge 를해야 첫번째 
개 발자가 작업한 내용을 S 어쓰지 않 는다. 이런 개념은 Subversion 과 같은 중앙 집중식 버견 관리 시 
스 템에서 사 용하는 방 식이고 Git 에서도 당연히 이런 Workflow 를 사용할 수 있다. 
팀이 작거나 이미 중앙집 중식에 격응한 상황 이라면 이 Workflow 에 따라 Git 을 도 입하여 사용할 수 있 
다. 중앙저 장소를 하나만 들고개 발자모 두에게 Push 권한 을부여 한다. 모 두에게 Push 권한을 부여해 
도 Git 은 한 개 발자가 다른 개 발자의 작업 내용을 덮어 쓰도록 허 용하지 않 는다. 한 개 발자가 Clone 하고 
나서 수 정하는 사이에 이미 다른개 발자가 중앙겨 장소에 무언가 Push 했다면 이 개 발자는 Push 할수 
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없다. Git 은 개발 자에게 지금 Push 하려는 커 밋으로 Fast-forward 할 수 없으니 Fetch 하고 Merge 해 
야 서버로 Push 할 수 있다고 알려 준다. 이런 개념은 개발 자에게 익 숙해서 거부감 없이 도입할 수 있다. 



5.1.2 Integration-Manager Workflow 

Git 을 사 용하면 리모트 저 장소를 여러 개 운영할 수 있다. 다른 개 발차는 읽기만 가 능하고 자신은 쓰기 
도 가능한 공개 저 장소를 만드는 Workflow 도 가능 하다. 이 Worlflow 에는 보통 프로 젝트를 대 표하는 
하나의 공식 저 장소가 있다. 기 여자는 우선 공식 저 장소를 하나 Clone 하고 수 정하고 나서 자신의 저장 
소에 Push 한다. 그 다음에 프 로젝트 Integration-Manager 에게 새 저장소 에서 Pull 하라 고요청 한다. 
그러면 그 Integration-Manager 는 기 여자의 겨 장소를 리모트 겨 장소로 등록 하고， 로 컬에서 기여물 
을 테스트 하고, 프 로젝트 메인 브 랜치에 Merge 하고， 그 내용을 다시 프 로젝트 메인 저 장소에 Push 한 
다. 이 런과정 은아래 와같다 (그림 5-2). 

1 . 프 로젝트 Integration-Manager 는 프 로젝트 메인 저 장소에 Push 를 한다. 

2. 프로 젝트기 여자는 메인 저 장소를 Clone 하고 수정 한다. 

3. 기 여자는 자신의 저 장소에 Push 하고 Integration-Manager 가 집근할 수 있도록 공개해 놓는 
다. 

4. 기 여자는 Integration-Manager 에게 변경 사항을 적용해 줄 것을 E-mail 갈은 것으로 요청한 
다. 

5. Integration-Manager 는 기 여자의 저 장소를 리모트 저 장소로 등 록하고 수정 사항을 Merge 하 
여 테스트 한다. 

6. Integration-Manager 는 Merge 한 사항을 메인 겨 장소에 Push 한다. 




이 방식은 GitHub 같 은사이 트에서 주로사 용하는 방식 이다. GitHub 는프로 젝트를 Fork 하고수 
정 사항을 반 영하여 다시 모 두에게 공 개하기 좋은 구조로 되어 있다. 이 방식의 장점은 기 여자와 
Integration-Manager 가 각자의 사정에 맞춰 프로 젝트를 유지할 수있다 는점이 다. 기 여자는 자신의 
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5.2 절 프로 젝트에 기 여하기 



겨 장소와 브탠 치에서 수정 작업을 계속해 나갈 수 있고 수정 사항이 프로 젝트에 반영 되도록 기다릴 필요 
가 없다. 관 리자는 여유를 가지고 기 여자가 Push 해 놓은 커밋을 격결한 시점에 Merge 한다. 

5.1.3 Dictator and Lieutenants Workflow 

이 방식은 저 장소를 여러개 운 영하는 방식을 변형한 구조 이다. 보통 수백 명의 개 발자가 참 여하는 
아주큰 프로젝 트를운 영할때 이방식 을사용 한다. 리 눅스커 널프로 젝트가 대표격 이다. 여 러명의 
Integration-Manager 가 저장소 에서 자신이 말은부 분만을 담당 하는데 이들을 Lieutenants 라고부 
튼다. 모든 Lieutenant 는 최종 관리자 아래에 있으며 이 최종 관 리차를 Dictator 라고 부른다 (그림 
5-3). 

1 . 개 발자는 코드를 수 정하고 master 브 탠치를 기 준으로 자신의 토픽 브 랜치를 Rebase 한다. 여기 
서 master 브 랜치란 Dictator 의 브 랜치를 말 한다. 

2. Lieutenant 들은 개발 자들의 수정 사항을 자신이 관 리하는 master 브 탠치에 Merge 한다. 

3. Dictator 는 Lieutenant 의 master 브 랜치를 자신의 master 브 랜치로 Merge 한다. 

4. Dictator 는 Merge 한 자신의 master 브 탠치를 Push 하여 다른 모든 개 발자가 Rebase 할 수 있 
는기준 으로만 든다. 




그림 5.3： Benevolent dictator Workflow 



이 방식이 일반 적이지 않지 만깊은 계층구 조를가 지는환 경이나 규모가 큰프로 젝트에 서는매 우쏠모 
있다. 프 로젝트 리더가 모든 코드를 통 합하기 견에 코드를 부 분부분 통합 하도록 여러 명의 Lieutenant 
에게 위임 한다. 

이 세 가지 Workflow 가 Git 같은 분산 버견 관리 시스 템에서 주로 사 용하는 것들 이다. 사실 이런 
Workflow 뿐만 아니라 다양한 변종 Workflow 가실재 로사용 된다. 어떤 방식을 선택하 고흑은 조합해 
야 하는 지 살짝 감이 잡힐 것 이다. 이 캉 에서는 몇 가지 구체적 사례를 들고 우리가 다양한 환 경에서 각 
역할을 어떻게 수행 하는지 살펴 본다. 

5.2 프로젝 트에기 여하기 

이미 다른 장에서 기 본적인 Git 사 용법에 대해서 배웠고 몇 가지 Workflow 도 살펴보 았다. 이제 이 절 
에서는 Git 으로 프로 젝트에 기 여하는 방법에 대해 배 운다. 

프로 젝트에 기 여하는 방식이 매우 다양하 다는점 을설명 하기란 정말어 렵다. Git 이 워낙유 연하게 설 
계됐기 때문에 사람들 은여러 가지 방 식으로 사용할 수 있다. 게다가 프로젝 트마다 환경이 달라서 프로 
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젝트 에기여 하는방 식을쉽 게설명 하기란 정말어 렵다. 기 여하는 방식에 영향을 끼치는 몇가지 변수가 
있다. 활발히 기 여하는 개 발자의 수가 얼마 인지, 선택한 Workflow 가 무엇 인지， 각 개발 자에게 집근 권 
한을 어떻게 부여했 는지, 외부에 서도기 여할수 있는지 등이 변 수다. 

첫 번째로 살펴볼 변수는 활발히 활 동하는 개 발자의 수 이다. 얼마나 많은 개 발자가 얼마나 자주 코드를 
쏟아 내는가 하는 점이 활발한 개 발자의 기준 이다. 대부분 들, 셋 정도의 개 발자가 하루에 몇번 커밋을 
하고 활 발하지 않은 프로 젝트는 더 띄엄 띄엄할 것 이다. 하 지만, 아주 큰 프로 젝트는 수백， 수천 명의 개 
발 자가하 루에도 수십， 수백 개의 커밋을 만들어 낸다. 개 발자가 많으면 많을 수록코 드를깥 끔하게 격용 
하거나 Merge 하기 어려워 진다. 어떤 것은 다른개 발자가 기여한 것으로 불필요 해지기 도하고 때론서 
로 충돌이 일어 난다. 어떻게 해야 코드를 최 신으로 유지 하면서 원하는 대로 수정할 수 있 을까? 
두 번째 변수는 프로젝 트에서 선택 한저장 소운영 방식 이다. 메인 저 장소에 개발 자모두 가쓰기 권한을 
가지는 중앙 집중형 방식 인가? 프로 젝트에 모든 Patch 를 검 사하고 통 합하는 관 리자가 따로 있 는가? 
모든수 정사항 을개발 자끼리 검 토하고 승인하 는가? 자신 도기여 이상의 역할을 하고있 는지? 중간관 
리자가 있어서 그 들에게 먼저 알 려야하 는가? 

세 번째 변 수는집 근권한 이다. '프 로젝 트에쓰 기권한 이있어 서직집 쏠수있 는가? 아 니면얽 기만가 
능한 가?' 에 따라서 프로 젝트에 기 여하는 방식이 매우 달라 진다. 쓰기 권한이 없다면 어떻게 수정 사항 
을 프로 젝트에 반영할 수 있 을까? 수정 사항을 적 용하는 정책이 프로 젝트에 있 는가? 얼마나 많은 시간 
을프로 젝트에 할애하 는가? 얼마 나자주 기여하 는가? 

이런 질문에 따라 프로 젝트에 기 여하는 방법과 Workflow 등이 달라 진다. 간단한 것부터 복잡한 것까 
지 각 상황을 살 펴보면 실제 프로 젝트에 필요한 방식을 선택할 수 있게 된다. 



5.2.1 커 밋가이 드라인 

다른 것보다 먼저 커밋 메 시지에 대한 주의 사항을 알아 보자. 커밋 메 시지를 잘 작 성하는 가이 드라인 
을알 아두면 다른 개발자 와함깨 일하는 데 도움이 많이 된다. Git 프로 젝트에 보면 커밋 메시지 를작성 
하는데 참고할 만한 좋 은팁이 많다. Git 프로 젝트의 'Documentation/SubmittingPatches' 문서를 
참고 하자. 

공백 문자를 깨 끗하게 정 리하고 커 밋해야 한다. Git 은 공백 문자를 검 사해볼 수 있는 간단한 명령을 제 
공 한다. 커밋 을하기 전에 git diff -check 명령으 로공백 문자에 대한오 류를확 인할수 있다. 아래 예 
제 를보면 잘못 사용한 공백을 'X' 문자로 바꾸어 표시해 준다: 



$ git diff —check 

lib/simplegit.rb:5: trailing whitespace. 
+ @git_dir = File. expand— path(git—dir)XX 
lib/simplegit.rb:7: trailing whitespace. 
+ XXXXXXXXXXX 

lib/ simplegit . rb ： 26 ： trailing whitespace. 
+ def command (git_cmd)XXXX 



커 밋을 하 7 1 전에 공백 문자에 대해 검사를 하면 공 백으로 불필 요하게 커 밋되는 것을 막 고이런 커 밋으 
로 인해 불필 요하게 다른 개발 자들이 신경 쓰는 일을 방지할 수 있다. 

그리고 각 커밋은 논리 격으로 구 분되는 Changeset 이다. 최대한 수정 사항을 하나의 주제로 요약할 수 
있어 야하고 여러 가지 이슈에 대 한수정 사항을 하나의 커밋에 담지 않아야 한다. 여러 가지 이 슈를한 
끼번에 수정 했다고 하 더라도 Staging Area 을 이 용하여 한 커밋에 하나의 이슈만 담 기도록 한다. 작업 
내용을 분할 하고, 각 커 밋마다 격결한 메 시지를 작성 한다. 같은 파일의 다른 부분을 수 정하는 경 우에는 
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git add -patch 명렁 을써서 한 부분씩 나누어 Staging Area 에 저장해 야한다 (관런 내용은 6 장에서 다 
툰다 ). 결과 격으로 최종 프로 젝트의 모습은 한 번에 커밋을 하든 다섯 번에 나누어 커밋을 하든 똑 같다. 
하 지만， 여러번 나누어 커 밋하는 것이 좋다. 다른 동료가 수정한 부분을 확인할 때나 각 커밋의 시점으 
로 복 원해서 검토할 때 이 해하기 휠썬 쉽다. 6 장에서 이미 저장된 커밋을 다시 수정 하거나 파일을 단계 
적으로 Staging Area 에 저 장하는 방법을 살펴 본다. 다양한 도 구를이 용해서 간 단하고 이 해하기 쉬운 
커 밋을쌓 아가야 한다. 

마지 막으로 명 심해야 할 점은 커밋 메시지 자체 다. 좋은 커밋 메 시지를 작 성하는 습관은 Git 을 사용하 
는 데 도움이 많이 된다. 일반 적으로 커밋 메 시지를 작성할 때 사 용하는 규칙이 있다. 메 시지의 첫 줄에 
50 자가 님지 않는 아주 간락한 메 시지를 격어 해당 커밋을 요약 한다. 다음 한 줄은 비우고 그다음 줄부 
터 커밋을 자세히 설명 한다. 예를 들어 Git 개발 프 로젝트 에서는 개발 동기와 구현 상황의 제약 조건이 
나 상황 등을 자 세하게 요구 한다. 이런 점은 따를 만한 좋은 가이 드라인 이다. 그리고 현재형 표현을 사 
용하는 것이 좋다. 예를 들어 "ᅵ added tests for (테 스트를 추가함 )" 보다는 "Add tests for (테 스트 
추가 )" 와같은 메시지 를작성 한다. 아래 예제는 Pope at tpope.net 이 작성 한커밋 메시지 이다. 



영문 50 글자 이하의 간락한 수정 요약 

자세한 설명. 영문 72 글자 이상이 되면 줄 바꿈을 하고 이 어지는 내용을 
작성 한다. 특정 상황 에서는 첫 번째 줄이 이메일 메 시지의 제목이 되고 
나 머지는 메일 내용이 된다. 간 략하게 요 약하고 넣는 빈 줄은 자세한 
설명을 아예 쓰지 않는 한 매우 중요 하다. 

이 어지는 내용도 한 줄 띄우고 쓴다. 

- 목록 표시도 사용할 수 있다. 

- 보통 '-' 나 ■*■ 표시를 사 용해서 목록을 표 현하고 표시 앞에 공백 
하나, 각 목록 사 이에는 빈 즐을 하나를 넣는데 상황에 따라 다 르다. 



메 시지를 이렇게 작 성하면 함께 일하는 사람은 물 론이고 자신 에게도 매우 유용 하다. Git 개발 프로젝 
트에는 잘쓰인 커밋 메 시지가 많으므 로프로 젝트를 내려 받아서 git log -no-merges 명 령으로 꼭살펴 
보 기를권 한다. 

이 책에서 설 명하는 예제의 커밋 메시지 는시간 관계상 위와 같이 아주 멋지게 쓰지 않 았다. git comit 
명 렁에서 -m 옵션 을사 용하여 간 단하게 적 는다. 하 지만! 겨 자처럼 하지 말 고시키 는대로 하서야 한다. 

5.2.2 비 공개소 규모팀 

두세 명으로 이 루어진 비공개 프로 젝트가 가장 간단한 프로 젝트일 것 이다. 비공 개라고 함은 소 스코드 
가 공 개되지 않은 것을 말하는 것이지 외 부에서 집근할 수 없는 것을 말하지 않 는다. 모든 개 발자는 공 
유 하는저 장소에 쓰기 권한이 있어야 한다. 

이런 환 경에서 는보통 Subversion 같 은중앙 집중형 버전 관리 시스 템에서 사 용하던 방식 을사용 한다. 
물론 Git 이 가진 오 프라인 커밋 기 능이나 브탠치 Merge 기능을 이 용하긴 하지만 크게 다르지 않다. 가 
장 큰 차 이점은 서버가 아닌 클라 이언트 쪽에서 Merge 한다는 점 이다. 두 개발 자가저 장소를 공 유하는 
시나 리오를 살펴보 차. 개발자 John 씨는 저 장소를 Clone 하고 파일을 수 정하고 나서 로걸에 커 밋한다 
(Git 이 출 력하는 메 시지는 . . . 으로 줄이고 생락한 다). 
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# John's Machine 

$ git clone john@githost :simplegit.git 

Initialized empty Git repository in /home/ john/simplegit/ . git/ 

$ cd simplegit/ 

$ vim lib/simplegit.rb 

$ git commit —am 1 removed invalid default value' 
[master 738ee87] removed invalid default value 
1 files changed, 1 insertions(+) f 1 deletions(-) 



개발자 Jessica 씨도 저 장소를 Clone 하고 나서 파일을 하나 새로 추 가하고 커밋 한다: 

# Jessica's Machine 

$ git clone jessica@githost: simplegit. git 

Initialized empty Git repository in /home/jessica/simplegit/.git/ 

$ cd simplegit/ 
$ vim TODO 

$ git commit —am 'add reset task 1 
[master fbff5bc] add reset task 
1 files changed, 1 insertions(+) , 0 deletions(-) 

Jessica 씨는 서버에 커밋을 Push 한다: 

# Jessica's Machine 

$ git push origin master 

To jessica@githost: simplegit .git 
1edee6b. .fbff5bc master -> master 

John 씨도 서버로 커밋을 Push 하려고 한다: 

# John's Machine 

$ git push origin master 

To john@githost: simplegit. git 

！ [rejected] master -> master (non-fast forward) 

error: failed to push some ref s to 1 j ohn@githost ： simplegit . git 1 

Jessica 씨의 Push 는 성공했 지만， John 씨의 커 밋은서 버에서 거걸 된다. Subversion 을사 용했던 사 
람은 이 부분을 이 해하는 것이 중요 하다. 같은 파일을 수정한 것도 아닌데 왜 Push 가 거 질되는 걸까? 
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Subversion 에 서는서 로다른 파일을 수정하 는이런 Merge 작업은 자동으 로서버 가처리 한다. 하 
지만， Git 은 로 컬에서 먼저 Merge 해야 한다. John 씨는 Push 하기 견에 Jessica 씨가 수정한 커밋을 
Fetch 하고 Merge 한다: 

$ git fetch origin 

From john@githost:simplegit 
+ 049d078. . .fbff5bc master ―〉 origin/master 

Fetch 하고 나면 John 씨의 로컬 저 장소는 그림 5-4 와 같이 된다. 



master 




origin/master 



그림 5.4: Fetch 하고 난 John 씨의 저장소 

John 씨는」 essica 씨가저 장소로 Push 했던 커밋과 를로컬 저 장소에 가져 왔다. 하 지만， Push 하기 견 
에 Fetch 한브 탠치를 Merge 해야 한다: 

$ git merge origin/master 
Merge made by recursive ᅵ 
TODO ！ 1 + 

1 files changed, 1 insertions(+) f 0 deletions(-) 

Merge 가 잘 이루 어지면 John 씨의 브 탠치는 그림 5-5 와 같은 상태가 된다. 

John 씨는 Merge 하고 나서 자신이 작업한 코드가 제대로 동작 하는지 확인 한다. 그 후에 공유 하는겨 

장소에 Push 한다: 

$ git push origin master 

To john@githost:simplegit .git 

fbff5bc. .72bbc59 master -> master 
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째- - 4b078 ) ^ ᅳ ^ ledee^^— ^Ta8ee < 72bbc ) 





fbff5 



origin/master 



그림 5.5: origin/master 브 랜치를 Merge 하고 난 후， John 씨의 저장소 

이제 John 씨의 저장소 는그림 5-6 처럼 되 었다. 



4b078 ) ^~ ^ ledee ) ~*~ ^ 738ee ^-4—^ 72bbc ) 








origin/master 



그림 5.6: Push 하고 난 후， John 씨의 저장소 

동시에 Jessica 씨 는토픽 브 랜치를 하나만 든다. issue54 브랜 치를만 들고세 번에 걸처서 커밋 한다. 
아직 John 씨의 커밋을 Fetch 하지 않은상 황이기 때문에 그림 5-7 과같은 상황이 된다. 



- 4b078 < ledee"^-< fbff5 8149a ^-^ 23ac6 ^-^ 4a"2 ^ 



1 



그림 5.7: Jessica 씨의 저장소 

Jessica 씨는」 ohn 씨의 작업 을적용 하려면 Fetch 를해야 한다: 



# Jessica's Machine 
$ git fetch origin 

From jessica@githost:simplegit 

fbff5bc. .72bbc59 master -> origin/master 



위 명렁 으로」 ohn 씨가 Push 한커밋 을모두 내려받 는다. 그러면 Jessica 씨의 저장소 는그림 5—8 과 
같은 상태가 된다. 
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「 ^ 




t 



그림 5.8: John 씨의 커밋을 Fetch 한후 Jessica 씨의 저장소 

이제 orgin/master 와 Merge 할차 례다. Jessica 씨 는토픽 브탠치 작업을 마치 고어떤 내용이 Merge 
되는지 git log 명렁으 로확인 한다: 

$ git log —no-merges origin/master A issue54 
commit 738ee872852dfaa9d6634e0dea7a324040193016 
Author: John Smith <j smith@example . com) 
Date: Fri May 29 16:01:27 2009 -0700 

removed invalid default value 

Merge 할 내용을 확인한 Jessica 씨는 자신이 작업한 내용과 John 씨가 Push 한 작업 (origin/master) 
을 master 브 탠치에 Merge 하고 Push 한다. 모든 내용을 합치기 전에 우선 master 브 탠치를 Checkout 
한다: 

$ git checkout master 
Switched to branch "master" 

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded, 
origin/master, issue54 모두 master 보다 Fast— forward 된 브탠 치이기 때문에 둘 중에 무엇을 먼저 

Merge 하든 상관이 없다. 물 론어떤 것을 먼저 Merge 하 느나에 따라 히 스토리 순서는 달라지 지만， 최 
종 결과는 똑 같다. Jessica 씨는 먼저 issue54 브 탠치를 Merge 한다: 

$ git merge issue54 
Updating fbff5bc. .4af4298 
Fast forward 

README ！ 1 + 

lib/simplegit.rb ！ 6 +++++— 

2 files changed, 6 insertions(+) , 1 deletions(-) 

보 다시피 Fast-forward Merge 이기 때문에 별 문제 없이 실행 된다. 다음은 John 씨의 커밋 (origin/ 
master) 을 Merge 한다: 
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$ git merge origin/master 
Auto— merging lib/simplegit.rb 
Merge made by recursive ᅳ 
lib/simplegit.rb ！ 2 +— 

1 files changed, 1 insertions(+) f 1 deletions(-) 



위와 같이 Merge 가 잘 되면 그림 5-9 와 같은 상태가 된다. 



I )•*— f 72bfao l< 




그림 5.9: Merge 이후 Jessica 씨의 저장소 

origin/master 브탠 치가」 essica 씨의 master 브 탠치로 나아갈 (reachable) 수있기 때문에 Push 는성 
공한다 (물론 John 씨가그 사이에 Push 를하지 않았다 면): 



$ git push origin master 



To j essica@githost ： simplegit . git 
72bbc59. .8059c15 master -> master 



개 발자의 커밋과 Merge 가 성공 격으로 이루 어지고 난 후의 결과는 5-1 0 과 같다. 
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그림 5.1 0: Jessica 씨가 서버로 Push 하고 난 후의 저장소 

여기서 살펴본 예제가 가장 간단한 상황 이다. 토픽 브탠 치에서 수 정하고 로컬의 master 브 랜치에 
Merge 한다. 작업한 내용을 프로 젝트의 공유 겨 장소에 Push 하고차 할 때에는 우선 origin/master 브랜 

치를 Fetch 하고 Merge 한다. 그리고 나서 Merge 한 결과를 다시 서버로 Push 한다. 이런 Workflow 
가 일반 적이고 그림 5-11 로 나타낼 수 있다. 



5.2.3 비 공개대 규모팀 

이제 비공개 대규모 팀 에서의 역할을 살펴 보자. 이런 상 황에는 보통 팀 을여러 개로 나 눈다. 그래서 각 
각의 작은 팀이 서로 어떻게 하나로 Merge 하 는지를 살펴 본다. 
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Jessica 




git commit 



3 



git merge 



3 



■ git clone furl) 



git push origin i 



gqit fetch origin 



git push origin i 




git clone (url) i 



git fetch origin > 



g'lit [：'|. i ■：-.!'! ᅵ :'nn in 



'lit f^tcl'i ᅵ: 'nniri | 



git commit 



5 



git merge 



5 



Jessica 





그림 5.1 1: 여러 개 발자가 Git 을사 용하는 Workflow 



John 씨와 Jessica 씨는 한 팀이고 프로젝 트에서 어떤 한 부분을 담당 한다. 또한， Jessica 씨와 Josie 
씨도 다튼 부분을 담 당하는 한팀 이다. 이런 상황 이라면 회사는 Integration- manager Workflow 를 
선 택하는 게 좋다. 작은 팀이 수행한 결 과물은 Integration-Manager 가 Merge 하고 공유 저 장소의 
master 브 탠치를 업 데이트 한다. 팀마다 브 랜치를 하나씩 만들고 Integration-Manager 는 그 브랜 
치를 Pull 해서 Merge 한다. 

두팀 에모두 속한 Jessica 씨의 작업 순서를 살펴 보자. 우선 Jessica 씨는 저 장소를 Clone 하고 
feature A 작업을 먼저 한다. feature A 브 랜치를 만들고 수정을 하고 커밋을 한다: 



# Jessica's Machine 
$ git checkout — b featureA 
Switched to a new branch "featureA" 
$ vim lib/simplegit.rb 

$ git commit -am 'add limit to log function ' 
[featureA 3300904] add limit to log function 
1 files changed, 1 insertions(+) , 1 deletions(-) 



이 수 정한부 분을」 ohn 씨와공 유해야 한다. 공유 하려면 우선 featureA 브 탠치를 서버로 Push 한다. 
Integration-Manager 만 master 브탠치 를업데 이트할 수 있기 때문에 master 브 탠치로 Push 를 할 
수 없고 다른 브 탠치로 John 과 공유 한다: 



$ git push origin featureA 
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To j essica@githost ： simplegit . git 
* [new branch] featureA -> featureA 



Jessica 씨는 자신이 한 일을 featureA 라는 브 탠치로 Push 했다는 이 메일을 John 씨에게 보 낸다. 
John 씨의 피 드백을 기 다리는 동안 Jessica 씨는 Josie 씨와 함께 하는 featureB 작업을 하기로 한다. 
서버의 master 브 탠치를 기 반으로 새로운 브 탠치를 하나 만 든다: 



# Jessica's Machine 
$ git fetch origin 

$ git checkout — b featureB origin/master 
Switched to a new branch "featureB" 



몇 가지 작업을 하고 featureB 브 탠치에 커밋 한다: 



$ vim lib/simplegit.rb 

$ git commit —am 'made the Is— tree function recursive 1 
[featureB e5b0fdc] made the ls-tree function recursive 

1 files changed, 1 insertions(+) , 1 deletions(-) 
$ vim lib/simplegit.rb 
$ git commit —am 'add Is— files' 
[featureB 8512791] add Is— files 

1 files changed, 5 insertions(+) f 0 deletions(-) 




그림 5/12: Jessica 씨의 저장소 

작업을 마치고 Push 하려고 하는데 Jesie 씨가 이 미일부 작업을 하고 서버에 featureBee 브 탠치로 
Push 했다는 이 메일을 보내 왔다. Jessica 씨는 Jesie 씨의 작업을 먼저 Merge 해야만 Push 할 수 있다. 
Merge 하기 위해서 우선 git fetch 로 Fetch 한다: 
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$ git fetch origin 

From jessica@githost:simplegit 
* [new branch] featureBee -> origin/featureBee 



Fetch 해 온 브 탠치를 git merge 명 렁으로 Merge 한다: 

$ git merge origin/featureBee 
Auto— merging lib/simplegit.rb 
Merge made by recursive ᅵ 

lib/simplegit.rb ！ 4 ++++ 

1 files changed, 4 insertions(+) f 0 deletions(-) 

Push 하려고 하는데 작은문 제가생 겼다. Jessica 씨는 featureB 브탠 치에서 작업을 했는데 서버에 
는브 탠치가 featureBee 라는 이 름으로 되어 있다. 그래서 git push 명 렁으로 Push 할 때 로컬 브탠치 
featureB 뒤에 콜론 (：) 과 함께 서버 브탠치 이름을 직접 지정해 준다: 

$ git push origin featureB: featureBee 
To j essica@githost ： simplegit . git 



fba9af8. .cd685d1 featureB -> featureBee 




이것은 refspec 이란 것을사 용하는 것인데 9 장에서 자세 하게 설명 한다. 

John 씨가 S 가지 작업을 하고 나서 featureA 에 Push 했고 확인해 달라는 내용의 이 메일을 보내 왔다. 

Jessica 씨는 git fetch 로 Push 한 작업을 Fetch 한다: 

$ git fetch origin 

From jessica@githost: simplegit 

3300904. .aad881d featureA -> origin/featureA 



어떤 것이 업 데이트 됐는지 git log 명렁으 로확인 한다: 

$ git log origin/featureA A feat 니 reA 
commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6 
Author: John Smith <j smith@example.com〉 
Date: Fri May 29 19:57:33 2009 -0700 

changed log output to 30 from 25 
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$ git checkout featureA 
Switched to branch "featureA" 
$ git merge origin/featureA 
Updating 3300904. .aad881d 
Fast forward 

lib/simplegit.rb ！ 10 +++++++++- 
1 files changed, 9 insertions(+), 1 deletions—) 

Jessica 씨는 일부 수정 하고， 수정한 내용을 다시 서버로 Push 한다: 

$ git commit —am 1 small tweak 1 
[featureA 774b3ed] small tweak 
1 files changed, 1 insertions(+) , 1 deletions(-) 
$ git push origin featureA 

To jessica@githost :simplegit .git 

3300904. .774b3ed featureA -> featureA 

위와 같은 작업을 마치고 나면 Jessica 씨의 저 장소는 그림 5— 1 3 과 같은 모습이 된다. 



origin/featureA 




origin/featureBee 



그림 5.1 3： 마지막 Push 하고 난 후의 Jessica 씨의 저장소 

그럼 featureA 와 featureBee 브 탠치가 프로 젝트의 메인 브 랜치로 Merge 할 준비가 되 었다고 
Integration-Manager 에게 알려 준다. Integration-Manager 가 두 브 탠치를 모두 Merge 하고 난 
후에 메인 브 탠치를 Fetch 하면 그림 5-1 4 와 같은 모양이 된다. 

수많은 팀의 작업을 동시에 진 행하고 나중에 Merge 하는 기능을 사용 하려고 다튼 버견 관리 시 스템에 
서 Git 으로 바꾸는 조 직들이 많 아지고 있다. 팀은 자신의 브 탠치로 작업하 지만, 메인 브 탠치에 영향을 
끼치지 않 는다는 점이 Git 의 장점 이다. 그림 5-1 5 는 이런 Workflow 을 나 타내고 있다. 
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ohgln/fuiureA 



featureA I I origin/master 



- { 4b07B ledee 330o7^-*-^aId88 J-*-^ 774b3 》 





orlgln/feaiureB«e 



그림 5.14: 두 브 랜치가 메인 브 랜치에 Merge 된 후의 저장소 




그림 5.1 5: 대규모 팀의 Workflow 



5.2.4 공개소 규모팀 

비공개 팀을 운 영하는 것과 공개 팀을 운 영하는 것은 약간 다 르다. 공개 팀을 운영할 때에는 모든 개발 
자가 프로 젝트의 공유 저 장소에 직집 적으로 쓰기 권한을 가 지지는 않 는다. 그래서 프로 젝트의 관리자 
는 몇 가지 일을 더 해줘야 한다. Fork 를 지 원하는 Git 호스 팅에서 Fork 를 통해 프로 젝트에 기 여하는 법 
을 예제를 통해 살펴 본다. repo.or.cz 나 Github 같은 Git 호스팅 사 이트는 Fork 기능을 지 원하며 프로 
젝트 관 리자는 보통 Fork 하는 것으로 프로 젝트를 운영 한다. 다른 방 식으로 이 메일과 Patch 를 사용하 
는 방식도 있는데 뒤이어 살펴 본다. 

우선 처음 할 일은 메인 저 장소를 Clone 하는 것 이다. 그리고 나서 토픽 브 랜치를 만들고 일정 부분 기 
여 한다. 그 순서는 아래와 같다: 



$ git clone (url) 
$ cd project 
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$ git checkout — b featureA 
$ (work) 
$ git commit 
$ (work) 
$ git commit 



rebase -i 명렁을 사 용하면 여러 커밋을 하나의 커 밋으로 합 치거나 프로 젝트의 관 리자가 수정 사항을 

쉽게 이해 하도록 커밋을 정리할 수 있다. 6 장에서 대화 식으로 Rebase 하는 방법을 살펴 본다. 
일단 프로 젝트의 웹사 이트로 가서 'Fork' 버튼을 누르면 원래 프 로젝트 저장 소에서 갈라져 나온， 쓰기 
권한이 있는 저장소 가하나 만들어 진다. 그러면 로 컬에서 수정한 커밋을 외부에 있 는그저 장소에 Push 
할 수 있다. 그 저 장소를 로걸 저 장소의 리모트 저 장소로 등록 한다. 예를 들어 myfork 로 등록 한다: 



$ git remote add myfork (url) 



자 이제 등록한 리모트 저 장소에 Push 한다. 작 업하던 것을 로컬 겨 장소의 master 브 랜치에 Merge 
한 후 Push 하는 것보다 리모트 브 랜치에 바로 Push 를 하는 방식이 휠썬 간단 하다. 이렇게 하는 이유 
는 관 리자가 토픽 브 탠치를 프로 젝트에 포함 시키고 싶지 않을 때 토픽 브 탠치를 Merge 하기 이전 상태 
로 master 브 탠치를 되들릴 필요가 없기 때문 이다. 관리자 가토픽 브 탠치를 Merge 하든 Rebase 하든 
cherry—pick 하든지 간에 결국 다시 관 리자의 저 장소를 Pull 할 때에는 토픽 브 랜치의 내용이 들어 있을 
것 이다: 



$ git push myfork featureA 

Fork 한 저 장소에 Push 하고 나면 프 로젝트 관리 자에게 이 내용을 알려야 한다. 이것을 'Pull Re- 
quest' 라고 한다. git 호스팅 사이 트에서 관리차 에게 보낼 메 시지를 생성 하거나 git request-pull 명령 
으로 이메 일을수 동으로 만들수 있다. GitHub 의 "pull request" 버 튼은자 동으로 메 시지를 만들어 준 
다. 

request-pull 명 령은아 규먼트 를두개 입력받 는다. 첫 번째 아 규먼트 는작업 한토픽 브 랜치의 Base 
브 탠치이 다. 두 번째는 토픽 브 탠치가 위치한 저장소 URL 인데 위에서 등록한 리모트 겨장소 이름을 적 
을 수 있다. 이 명렁은 토픽 브탠치 수정 사항을 요약한 내용을 결과로 보여 준다. 예를 들어 Jessica 씨가 
John 씨에게 Pull 요청을 보내는 상황을 살펴 보자. Jessica 씨는 토픽 브 랜치에 두번 커밋을 하고 Fork 
한저 장소에 Push 했다. 그리 고아래 와같이 실행 한다: 

$ git request-pull origin/master myfork 

The following changes since commit 1 edee6b1 d61 823a2de3b09c1 60d7080b8d1 b3a40 ： 
John Smith (1)： 

added a new function 

are available in the git repository at: 
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git://githost/simplegit .git feat 니 reA 

Jessica Smith (2) ： 

add limit to log function 
change log output to 30 from 25 



lib/simplegit.rb ！ 10 +++++++++— 

1 files changed, 9 insertions(+) , 1 deletions(-) 



관리 자에게 이 내 용을보 낸다. 이 내용에 는토픽 브탠치 가어느 시점에 갈라겨 나온것 인지， 어떤 커밋 

이 있 는지, Pull 하려면 어떤 저 장소에 집근 해야하 는지에 대한 내용이 들어 있다. 

프 로젝트 관 리자가 아 니라고 해도 보통 origin/master 를 추 격하는 master 브 랜치는 가지고 있다. 그 
래도 토픽 브 탠치를 만들고 일을 하면 관 리자가 수정 내용을 거부할 때 쉽게 버릴수 있다. 토픽 별로 브 
탠치를 분 리해서 일을 하면 그동안 주 겨 장소의 master 브 탠치가 수 정됐기 때문에 깨끗한 커밋을 남길 
수 없을 수도 있지만 Rebase 로 깨 끗하게 Merge 할 수 있다. 그리고 토픽 브 탠치를 새로 만들 때 앞서 
Push 한토픽 브탠 치에서 시 작하지 말 고주저 장소의 master 브탠치 로부터 만 들어야 한다: 



$ git checkout — b featureB origin/master 
$ (work) 
$ git commit 

$ git push myfork featureB 
$ (email maintainer) 
$ git fetch origin 



그림 5- 1 6 처럼 각 토픽은 일종의 실험실 이라고 할 수 있다. 각 토픽은 서로 방 해하지 않고 독립 적으로 
수 정하고 Rebase 할수 있다: 



master 


1 origin/master 









- - 4b07B ) 뻬ᅳ^ ledee ) 쌜 ( 33009 ) 




^ ~~ ( 0d708 ^ ᅳ ^ 



빼 featureB 



그림 5.1 6： featureB 수정 작업이 끝난 직후 저 장소의 모습 



프 로젝트 관리 자가사 람들의 수정 사항을 Merge 하고 나서 Jessica 씨의 브 랜치를 Merge 하려고 할 때 
충돌이 날수도 있다. 그러면 Jessica 씨가차 신의브 탠치를 origin/master 에 Rebase 해서충 돌을해 
결하고 다시 Pull Request 을보 낸다: 
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$ git checkout featureA 
$ git rebase origin/master 
$ git push — f myfork featureA 



위 명 령들을 실 행하고 나면 그림 5-1 7 과 같아 진다. 




그림 5.17: FeatureA 에 대한 Rebase 가 적용된 후의 모습 



브 랜치를 Rebase 해 버렸기 때문에 Push 할때 -f 옵선 을주고 강제로 기존에 서버에 있던브 랜치의 내 
용 을덮어 써야 한다. 아니면 새 로운브 랜치를 (예 를들어 featureAv2) 서버에 Push 해도 된다. 
또 다른 시나 리오를 하나 더 살펴 보자. 프 로젝트 관 리자는 featureB 브 탠치의 내용은 좋 지만, 상세 
구현은 다르게 하고 싶다. 관 리자는 featureB 담당 자에게 상세 구현을 다르게 해 달라고 요청 한다. 
featureB 담 당차는 하는 김에 featureB 브 랜치를 프로 젝트의 최신 master 브탠치 기 반으로 옮 긴다. 
먼겨 origin/master 브탠 치에서 featureBv2 브 랜치를 새로 하나 만 들고, featureB 의 커 밋들을 모두 
Squash 해서 Merge 하고， 만약 충돌이 나면 해결 하고, 상세 구현 을수정 하고, 새 브 탠치를 Push 한다: 

$ git checkout — b featureBv2 origin/master 
$ git merge ―— no-commit —squash featureB 
$ (change implementation) 
$ git commit 

$ git push myfork featureBv2 



- squash 옵션은 현재 브 탠치에 Merge 할 때 해당 브 랜치의 커밋을 모두 하나의 커 밋으로 합처서 
Merge 한다. - no-commit 옵션을 주면 Git 은 Merge 하고 나서 자 동으로 커 밋하지 않 는다. 다른 브 
탠치의 수정 사항을 통째로 새로운 브 탠치에 Merge 하고 나서 좀 더 수 정하고 커밋 하나를 새로 만 든다. 
수정을 마치면 관리 자에게 featureBv2 브 탠치를 확인해 보라고 메 시지를 보낸다 (그림 5-18 참고 ). 

5.2.5 대규모 공개프 로젝트 

대규모 프로 젝트는 보통 수정사 항이나 Patch 를 수 용하는 자 신만의 규칙을 마련 해놓고 있다. 프 로젝트 
마다 규칙은 서로 다를 수 있 으므로 각 프로 젝트의 규칙 을미리 알아둘 필요가 있다. 대규모 프로 젝트는 
대부분 메 일링리 스트를 통해서 Patch 를 받아들 이는데 예제 를통해 살펴 본다. 
토픽 브 탠치를 만들어 수 정하는 작업은 앞서 살펴본 바와 거의 비숫하 지만， Patch 를 제 출하는 방식이 
다 르다. 프로 젝트를 Fork 하여 Push 하는 것이 아니라 커밋 내용을 메일로 만들어 개발자 메일 링리스 
트에 제출 한다: 
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master I I origin /master 



- 4b078 ^ ledee ) 째 ^3 



( dee6b ᅳ ( 5399e ) 뺴 ᅳ j| 
( e5bQf }， ~~ f^c 



그림 5.18: featureBv2 브 랜치를 커밋한 이후 저장소 모습 



$ git checkout — b topicA 
$ (work) 
$ git commit 
$ (work) 
$ git commit 



커밋 을두번 하고 메 일링리 스트에 보내 보자. git format-patch 명 렁으로 메 일링리 스트에 보낼 mbox 
형식 의파일 을생성 한다. 각 커밋은 하나씩 메일 메시지 로생성 되는데 커밋 메 시지의 첫 번째 줄이 제목 

이 되고 Merge 메시지 내용과 Patch 자체 가메일 메 시지의 본문이 된다. 이 방 식은수 신한이 메일에 
들어 있는 Patch 를 바로 격용할 수 있어서 좋다. 메일 속에는 커밋의 모든 내용이 포함 된다. 메일에 포 
함된 Patch 를 적 용하는 것은 다음 질에서 살펴 본다. 



$ git format-patch — M origin/master 

0001 — add— limit— to— log"f unction . patch 

0002— changed— log— output— to— 30— from— 25 . patch 



format-patch 명 렁을실 행하면 생성 한파일 이름 을보여 준다. -M 웁션은 이름이 변경된 파일이 있 
는지 살 펴보라 는웁션 이다. 각 파일의 내용은 아래와 같다: 



$ cat 0001 -add-limit-to-log-f unction . patch 

From 330090432754092d704da8e76ca5c05c1 98e71 a8 Mon Sep 17 00:00:00 2001 

From: Jessica Smith <jessica@example.com> 

Date: Sun, 6 Apr 2008 10:17:23 -0700 

Subject: [PATCH 1/2] add limit to log function 



Limit log functionality to the first 20 



lib/simplegit.rb ！ 2 +— 

1 files changed, 1 insertions(+) , 1 deletions(-) 
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diff —git a/lib/simplegit.rb b/lib/simplegit.rb 
index 76f47bc. .f9815f1 100644 
— a/lib/simplegit.rb 
+++ b/lib/simplegit.rb 
@@ -14,7 +14,7 @@ class SimpleGit 
end 

def log(treeish = 'master' ) 
― command( "git log #{treeish}") 
+ command( "git log — n 20 #{treeish}" ) 

end 

def ls_tree(treeish = 'master' ) 
1.6.2.rc1 . 20. g8c5b. dirty 



메 일링리 스트에 메일을 보내기 전에 각 Patch 메일 파일의 내용 을손으 로고칠 수 있다. —즐과 Patch 

가시작 되는즐 (lib/simplegit.rb 로 시작하 는줄) 사이에 내 용을추 가하면 개 발자는 읽 을수있 지만， 나 

중에 Patch 에 격용되 지는않 는다. 

특정 메일프 로그램 을사용 하거나 이메일 을보내 는명렁 어로메 일링리 스트에 보낼수 있다ᅳ 붙여 넣기 
로 위의 내용이 그대로 들 어가지 않는 메일 프로 그램도 있다ᅳ 사용자 편의를 위해 공 백이나 즐 바꿈 문 
자 등을 넣어 주는 메일 프로 그램은 원본 그대로 들 어가지 않 는다. 

다행히 Git 에는 Patch 메일을 그대로 보널 수 있는 도구가 있다. IMAP 프로 토콜로 보 낸다. 저 자가사 
용하는 방 법으로 Gmail 을 사 용하여 Patch 메일을 견 송하는 방법을 살펴 보자. 추가로 Git 프로 젝트의 

Documentation/SubmittingPatches 문서의 □ ᅡ지막 부분을 살 펴보면 다양한 메일 프로그 램으로 메일을 보 
내 는방법 을설명 한다. 

메 일을보 내려면 먼저 〜/.git C onfig 파 일에서 이메일 부 분설정 한다. git config 명렁으 로추가 할수도 
있고 직집 파일을 열어서 추가할 수도 있다. 아 무튼， 아래와 같이 설정을 한다: 

[imap] 

folder = "[Gmail] /Drafts" 
host = imaps ： //imap . gmail . com 
user = 니 ser@gmail.com 
pass = p4ssw0rd 
port = 993 
sslverify = false 



ᅵ MAP 서버가 SSL 을사 용하지 않으면 마지 막두즐 은필요 없고 host 에서 imaps:// 대신 imap:// 로한 
다. 이 렇게설 정하면 git imap-send 명렁 으로메 일을견 송할수 있다: 

$ cat *. patch Igit imap— send 
Resolving imap.gmail.com. . . ok 
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5.2 절 프로섹 트에기 여하기 



Connecting to [74.125.142.109] ：993. . . ok 
Logging in..- 
sending 2 messages 
100% (2/2) done 



이후 Gmail 의 Draft 폴더로 가서 To 부분을 메 일링리 스트의 주소로 변 경하고 CC 부분에 해당 메일을 
참 고해야 하는 관 리차나 개 발자의 메일 주소를 격고 실제로 견송 한다. 

SMTP 서 버로도 패치를 보낼수 있다. git config 명 렁으로 설정을 하나씩 입력하 거나〜 /.gitconfig 파 

일의 sendmail 부분을 손으로 직집 수정 한다: 

[sendemail] 
smtpencryption = tls 
smtpserver = smtp. gmail .com 
smtp 니 ser = user@gmail.com 
smtpserverport = 587 



이렇게 했으면 git send-mail 로패 치룰보 낸다: 

$ git send— email *. patch 

0001 — added— limit— to— log— function . patch 

0002— changed— log— output— to— 30— f ran— 25 . patch 

Who should the emails appear to be from? [Jessica Smith <j essica@example . com) ] 
Email ' s will be sent from: Jessica Smith <jessica@example.com〉 
Who should the emails be sent to? jessica@example.com 
Message-ID to be used as In— Reply— To for the first email? y 



Git 으로 메일을 보내면 아래와 같은 로그 메 시지가 출력 된다: 

(mbox) Adding cc: Jessica Smith <j essica@example . corn) from 

Mine 1 From: Jessica Smith 〈； jessica@example.com〉' 
OK. Log says: 

Sendmail: /usr/sbin/sendmail — i jessica@example.com 
From: Jessica Smith <jessica@example.com> 
To: j essica@example.com 

Subject: [PATCH 1/2] added limit to log function 
Date: Sat, 30 May 2009 13:29:15 -0700 

Message-Id ： <1 24371 5356-61 726-1 —git— send— email— j essica@example . com> 
X— Mailer: git-send-email 1 .6.2.rc1 . 20. g8c5b. dirty 
In— Reply— To: <y> 
References: <y> 
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Result: OK 



5.2.6 요약 

이번 절 에서는 다양한 Workflow 에 따라 Git 을 어떻게 사 용하는 지 살 펴보고 그에 필요한 도 구들을 
설명 했다. 다음 결에서 는동전 의뒷면 인프로 젝트를 운영하 는방법 에대하 여살펴 본다. 즉 친절한 
Dictator 나 Integraticin-Manager 가되어 보는 것 이다. 

5.3 프로 젝트운 영하기 

효율 적으로 기 여하는 방 법뿐만 아니라 효을 적으로 운 영하는 방법도 알아야 한다. 언 젠가는 단순히 프 
로 젝트에 기여하 는것이 아 니라프 로젝트 를직집 운 영해야 할수도 있다. 프로젝 트를운 영하는 것은크 

게 두 가지로 이루어 진다. 하나는 format-patch 명 령으로 생성한 Patch 를 이 메일로 받아서 프 로젝트 
에 Patch 를 적 용하는 것 이다. 다른 하나는 프로 젝트의 다른 리모트 겨장소 로부터 변경 내용을 Merge 
하는 것 이다. 저 장소를 아주 깥 끔하고 정돈된 상태로 운 영하고 Patch 를 적용 하거나 수정 사항을 확인하 
기 쉬 운상태 를유지 하려면 좋 은운영 방식을 터 득해야 한다. 좋 은운영 방식은 다른사 람들이 이 해하기 
쉽고 프로 젝트가 오 랫동안 운 영돼도 흐트 러김이 없어야 한다. 

5.3.1 토 픽브랜 치에서 일하기 

메인 브 랜치에 통 합하기 전에 임시로 토픽 브탠치 를하나 만들고 거기에 통합해 보고 나서 다시 메인 브 
탠치에 통 합하는 것이 좋다. 이렇게 하면 Patch 를 적용할 때 이 리저리 수정해 보기도 하고 좀 더 고민해 
봐야 하면 Patch 를 적 용해둔 채로 나 중으로 □ I 룰 수도 있다. 무슨 Patch 인지 브탠치 이름에 간단히 격 
어주면 다른 작업을 하다가 나중에 이 브 랜치로 돌 아왔을 때 기억 해내기 휠썬 수월 하다. 프로 젝트의 관 
리자 라면 이런 토픽 브 탠치의 이 름을잘 지어야 한다. 예 를들어 sc 라는 사람이 작업한 Patch 라면 sc / 
ruby.dient 처럼 앞에 닉 네임을 붙여서 브 탠치를 만들수 있다. master 브랜 치에서 새 토픽 브 탠치를 

아래와 같이만 든다: 



$ git branch sc/ruby— client master 



checkout -b 명 령으로 브 탠치를 만들고 Checkout 까지 한 번에 할 수 있다: 



$ git checkout — b sc/ruby_client master 

이렇게 토픽 브 탠치를 만들고 Patch 를 격용 해보고 격용한 내용을 다시 Long-Running 브 랜치로 
Merge 한다. 

5.3.2 이 메일로 받은 Patch 를 적 용하기 

이 메일로 받은 Patch 를 프로 젝트에 적 용하기 견에 우선 토픽 브 탠치에 Patch 를 적용해 본다. Patch 
를적 용하는 방법은 git apply 명렁을 사용하 는것과 git am 명령을 사용하 는것두 가지가 있다. 
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5.3 절 프로 젝트운 영하기 



apply 명령을 사용하 는방법 

git diff 나 Unix 의 diff 명령으 로만든 Patch 파일을 적용할 때에는 git apply 명렁 을사용 한다. Patch 

파일이 /tmp/patch— ruby— client. patch 라고 하면 아래와 같은 명 령으로 Patch 를 적 용할수 있다: 



$ git apply /tmp/patch-ruby-client . patch 



위 명 렁을실 행하면 Patch 파일 내용에 따 라현계 디텍 토리의 파 일들을 변경 한다. 위 명령은 patch - P 1 
명령 과거의 같다. 하 지만, 이 명령이 patch 명령보 다월썬 더 꼼 꼼하게 비교 한다. git diff 로 생성한 
Patch 파일에 파일을 추가하 거나, 파일을 삭제 하고, 파일의 이름을 변 경하는 내용이 들어 있으면 그대 
로 적용 된다. 이런 것은 patch 명 령으로 할 수 없다. 

그리고 git apply 는 "모두 적용, 아니면 모두 취소" 모델을 사 용하기 때문에 Patch 를 격 용하는 데 실패 
하면 Patch 를 적 용하기 이전 상태로 견부 되들려 놓 는다. Patch 명령 은여러 파일에 격용 하다가 중간 
에 실 패하면 거기서 그대로 중 단하기 때문에 깥 끔하지 못 하다. git apP i y 는 Patch 보다 월썬 결 벽증적 
이다. 이 명령은 자 동으로 커밋해 주지 않기 때문에 변경된 파일을 직접 Staging Area 에 추 가하고 커 
밋해야 한다. 

실제로 Patch 를 격 용하기 건에 Patch 가 잘 격용 되는지 한 번 시험해 보려면 git apply -check 명령을 

사용 한다: 

$ git apply ― check 0001— seeing— if— this— helps— the— gem. patch 
error: patch failed: ticgit.gemspec:l 
error: ticgit.gemspec: patch does not apply 

화면에 아무런 내용도 뜨지 않으면 Patch 가깔 끔하게 적용 된다는 것 이다. 이 명렁은 Patch 를 적용해 
보고 에러가 발 생하면 0 이 아닌 값을 반 환하기 때문에 쉘 스 크립트 에서도 사용할 수 있다. 

am 명령을 사용하 는방법 

프 로젝트 기 여자가 Git 의 format-patch 명렁을 잘 사 용하면 관 리자의 작업은 휠썬 쉬워 진다. 
format- patch 명 렁으로 만든 Patch 파일은 기 여자의 정보와 커밋 정보가 포 함되어 있기 때문 이다. 
그래서 기 여차가 diff 보다 format-patch 를사용 하도록 권해야 한다. git apply 는 기존의 Patch 파일 
에 만사용 한다. 

format-patch 명 렁으로 생성한 Patch 파일은 git am 명령으 로적용 한다. git ^은 메일여 러통이 
들어 있는 mbox 파일을 읽어서 Patch 한다. mbox 파일은 간단한 텍스트 파 일이고 그 내용은 아래와 같 
다: 

From 330090432754092d704da8e76ca5c05c1 98e71 a8 Mon Sep 17 00:00:00 2001 

From: Jessica Smith <jessica®example . com> 

Date: Sun, 6 Apr 2008 10:17:23 -0700 

Subject: [PATCH 1/2] add limit to log function 

Limit log functionality to the first 20 
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이 내용은 format-patch 명 렁으로 생성한 파일의 앞부분 이다. 이 파일은 mbox 형식 이다. 받 은메일 

이 git send-email 로 만든 메일 이라면 mbox 형 식으로 저 장하고 이 mbox 파일을 git am 명 령으로 격 

용 한다. 사 용하는 메일 클라이 언트가 여러 메일을 하나의 mbox 파일로 저장할 수 있다면 메일 여러 개 
를 한번에 Patch 할수 있다. 

이 메일로 받은 것이 아니라 이슈 트래킹 시스템 같은데 올라온 파일 이라면 먼저 내려 받고서 git an 명 
렁으로 Patch 한다: 



$ git am 0001— limit— log— function. patch 
Applying: add limit to log function 




Patch 가 성 공하면 자 동으로 새로운 커밋이 하나 만들어 진다. Patch 파일에 들어 있는 기 여자의 이메 
일， 작성 시간, 커밋 메 시지를 뽑아서 커밋에 함께 저장 한다. 예 를들어 위의 mbox 예제 파일을 격용해 
서생 성되는 커밋은 아래와 같다: 



$ git log ― pretty=fuller -1 
commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 
Author: Jessica Smith <jessica@example.com> 
AuthorDate: Sun Apr 6 10:17:23 2008 -0700 
Commit: Scott Chacon <schacon@gmail .com) 
CommitDate: Thu Apr 9 09:19:06 2009 -0700 

add limit to log function 



Limit log functionality to the first 20 




커밋 정보는 누가 언제 Patch 했는 지 알려 준다. Author 정보는 실제로 누가 언제 Patch 파일을 만들 
었는지 알려 준다. 

Patch 에 실패 할수도 있다. 보통 Patch 가 생성된 시 점보다 해당브 탠치가 너무 업 데이트 됐을 때나아 
직격용 되지않 은다른 Patch 가필요 한경우 에일어 난다. 이러면 git am 명렁은 Patch 를중단 하고사 
용자 에게어 떻게처 리할지 물어 온다: 



$ git am 0001 -seeing-if-this-helps-the-gem. patch 
Applying: seeing if this helps the gem 
error: patch failed: ticgit.gemspec:l 
error: ticgit.gemspec: patch does not apply 
Patch failed at 0001 . 

When you have resolved this problem run "git am ―— resolved" . 

(춤 들을 해 결하면 "git am -resolved" 입력) 
If you would prefer to skip this patch, instead run "git am —skip" . 

(Patch 적용을 생략 하려면 "git am -skip" 입력) 
To restore the original branch and stop patching run "git am ―— abort" . 

(Patch 적용을 중단 하려면 "git am -abort" 입력) 
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성공 격으로 Patch 하지 못하면 git 은 Merge 나 Rebase 의 경 우처럼 문제를 일으킨 파일에 충돌 표시 
를 해 놓 는다. Merge 나 Rebase 할 때 충돌을 해 결하는 것처럼 Patch 의 충돌도 해결할 수 있다. 충돌 
한 파일을 열어서 충돌 부분을 수 정하고 나서 Staging Area 에 추 가하고 git am -resolved 명 렁을입 
력 한다: 



$ (fix the file) 

$ git add ticgit.gemspec 

$ git am ―— resolved 

Applying: seeing if this helps the gem 



충돌이 났을때 Git 에 게좀더 머리 를써서 Patch 를적용 하도록 하려면 -3 옵션 을사용 한다. 이 옵션은 
Git 에게 3_way Patch 를 적용해 보라고 하는 것 이다. Patch 가 어느 시 점에서 갈라겨 나온 것인지 알 
수 없기 때문에 이 옵션 은기본 적으로 비활 성화돼 있다. 하 지만, 같 은프로 젝트의 커밋 이라면 기 본옵션 
보다 휠썬 똑 똑하게 충돌 상황을 해결 한다. 



$ git am -3 0001 -seeing-if-this-helps-the-gem. patch 
Applying: seeing if this helps the gem 
error: patch failed: ticgit.gemspec :1 
error: ticgit.gemspec: patch does not apply 
Using index info to reconstruct a base tree... 
Falling back to patching base and 3— way merge. . . 
No changes ―— Patch already applied. 



위의 경우 는이미 Patch 한 것을 다시 Patch 하는 상황 이다. -3 웁션이 없 었으면 충돌을 알아서 해결하 
지 못 했을것 이다. 

하나의 mbox 파일에 들어 있는 여러 Patch 를 격용할 때 대화형 방식을 사용할 수 있다. 이 방식을 사 
용하면 Patch 를격 용하기 견에 Patch 를격 용할때 마다묻 는다: 



$ git am -3 — i mbox 
Commit Body is: 



seeing if this helps the gem 



Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all 




이 옵션은 Patch 를 여러 개 격용할 때 유용 하다. 적용 하려는 Patch 의 내용을 미리 꼭기억 해두지 않아 
도 되고적 용하기 견에 이미 격용된 Patch 인지 알수 있다. 

모든 Patch 를토픽 브 탠치에 적 용하고 커 밋까지 마치면 Long-Running 브 랜치에 어떻게 통합 할지를 
결 정해야 한다. 
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5.3.3 리모트 브탠치 로부터 통 합하기 

프로 젝트기 여자가 자신의 저 장소를 만들고 커밋 을몇번 하고 저 장소의 URL 과 변경 내용을 메일로 보 
내 왔다면 URL 을 리모트 저 장소로 등 록하고 Merge 할 수 있다. 

예 를들어 Jessica 씨는 ruby-client 브 랜치에 엄청 난기능 을만들 어놨다 고메일 을보내 왔다. 이 리모 
트 브 탠치를 등 록하고 Checkout 해서 테스트 한다: 

$ git remote add jessica git://github.com/jessica/myproject.git 
$ git fetch jessica 

$ git checkout — b rubyclient jessica/ruby— client 



후에 Jessiaca 씨가 이 메일로 또 다른 엄청난 기능을 개발한 브 랜치를 보 내오면 이미 저 장소를 등록했 
기 때문에 간단히 Fetch 하고 Checkout 할 수 있다. 

다른 개발 자들과 함께 지속 적으로 개발할 때는 이 방식이 가장 사 용하기 좋다. 물론기 여하는 사람이 
간단한 Patch 를 이따 금씩만 만들어 내면 이 메일로 Patch 파일을 받는 것이 낫다. 기 여자가 저장소 서 
버를 만들어 커 밋하고 관 리자가 리모트 저 장소로 등 록해서 Patch 를 합치는 작 업보다 시간과 노력이 덜 
든다. 물론 Patch 한두 개를 보내는 사람들 까지도 모두 리모트 저 장소로 등 록해서 사 용해도 된다. 스크 
립트나 호스팅 서 비스를 사 용하면 좀 더 쉽게 관리할 수 있다. 어쨌 든어떤 방식이 좋 을지는 우리가 어 
떻게 개 발하고 어떻게 기여 할지에 달 렀다. 

리모트 저 장소로 등 록하면 커밋의 히스 토리도 알 수 있다. Merge 할 때 어디서 부터 커밋이 갈 라쳤는 
지 알 수있기 때문에 -3 옵션을 주지 않아도 자 동으로 3-way Merge 가격용 된다. 
리모트 저 장소로 등 록하지 않고도 Merge 할 수 있다. 계속 함께 일할 개 발자가 아닐 때 사 용하면 좋다. 
아래는 리모트 저 장소로 등 록하지 않고 URL 을 직집 사 용하여 Merge 를 하는 예 이다: 

$ git pull git://github.com/onetimeguy/project .git 
From git://github.com/onetimeguy/project 
* branch HEAD -> FETCHJEAD 

Merge made by recursive. 



5.3.4 무 슨내용 인지확 인하기 

기 여물이 포함된 토픽 브 탠치가 있으니 이제 그 기 여물을 Merge 할지 말지 결정야 한다. 이번 결에서 
는 메인 브 탠치에 Merge 할 때 필요한 명 렁어를 살펴 본다. 주로 토픽 브 랜치를 검토 하는데 필요한 명령 
이다. 

먼저 지금 작 업하는 브랜 치에서 master 브 랜치에 속하지 않는 커밋만 살 펴보는 것이 좋다. - not 옵 
션으로 히스토 리에서 master 브 랜치에 속한 커밋은 제 외하고 살펴 본다. 예를 들어 contrib 브 랜치에 
Patch 를 두 개 Merge 했으면 아래와 같은 명 렁어로 그 결 고ᅡ를 살펴볼 수 있다: 

$ git log contrib —not master 
commit 5b6235bd297351 589efc4d7331 6f0a68d484f1 1 8 
Author: Scott Chacon <schacon@gmail . com) 
Date: Fri Oct 24 09:53:59 2008 -0700 
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seeing if this helps the gem 

commit 7482e0d16d04bea79d0dba8988cc78df655f16a0 
Author: Scott Chacon 〈schacon@gmail.com〉 
Date: Mon Oct 22 19:38:36 2008 -0700 



updated the gemspec to hopefully work better 




git log 명령에 _p 옵션을 주면각 커밋에 서실제 로무슨 내용이 변경됐 는지살 펴볼수 있다. 이 옵션은 
각 commit 의 뒤에 diff 의 내용을 출력해 준다. 

토픽 브 탠치를 다른브 랜치에 Merge 하기 견에 어떤 부분이 변 경될지 미리 살 펴볼수 있다. 이 때는색 
다른 명렁을 사 용해야 한다. 물론 아래와 같은 명렁을 사용할 수도 있다: 



$ git diff master 



이 명령은 diff 내용을 보 여주긴 하지만 잘못된 것을 보여줄 수도 있다. 토픽 브탠 치에서 작 업하는 동안 

master 브 탠치에 새로운 커밋이 추가될 수도 있다. 그래서 기 대하는 diff 결과가 아닐 수 있다. 지금 이 
명령 은각브 탠치의 마 지막스 냅샷을 비교 한다. master 브 랜치에 한 줄을추 가되면 토픽 브탠 치에서 
한 줄삭제 한것으 로보여 준다. 

master 브랜 치가가 리키는 커밋이 토픽 브 탠치의 조상 이라면 아무 문제 없다. 하지 만， 그렇지 않은 경 
우라면 이 diff 도구는 토픽 브탠 치에만 있는 내용은 추 가하는 것이고 master 브탠 치에만 있는 내용은 
삭제하 는것으 로간주 한다. 

정말 보고 싶은 것은 토픽 브 탠치에 추가한 것이고 결 국에는 이것을 master 브 탠치에 추가 하려는 것이 
다. 그 러니까 master 브 랜치와 토픽 브 탠치의 공통 조상인 커밋을 찾아서 토픽 브 탠치가 현재 가리키 
는커 밋과비 교해야 한다. 

아래와 같은 명 렁으로 공통 조상인 커밋을 찾고 이 조상 커 밋에서 변경된 내용을 살펴 본다: 



$ git merge— base contrib master 
36c7dba2c95e6bbb78dfa82251 9ecfec6e1 ca649 
$ git diff 36c7db 



이 방 법으로 원하는 결과를 얻을 수 있 지만， 사 용법이 불편 하다. Git 은 Triple-Dot 으로 간 단하게 위와 
같이 비교하 는방법 을지원 한다. diff 명렁 을사용 할때두 브탠치 사이에 …를 쓰면， 두브 탠치의 공통 
조상과 브 탠치의 마지막 커밋을 비교 한다: 



$ git diff master. . .contrib 



이 명렁은 master 브랜치 로부터 현재 토픽 브 랜치의 다른것 들만보 여주기 때문에 기억 해두면 매우유 
용 하게사 용할수 있을것 이다. 

131 



5 장 분 산환경 에서의 Git 



Scott Chacon Pro Git 



5.3.5 기 여물통 합하기 

기 여물을 토픽 브 탠치에 다 적 용하고 Long-Running 브 탠치나 master 브 랜치로 통합할 준비가 되었 
다면 이제 어떻게 해야 할까? 프로 젝트를 운 영하는 데 쓰는 작업 방식 은어떤 것이 있 을까? 앞으로 그 
예제 몇가지 를살펴 본다. 

Merge Workflow 

바로 master 브 랜치에 Merge 하는 것이 가장 간단 하다. 이 Workflow 에서는 master 브 랜치가 안 
견한 코 드라고 가정 한다. 토픽 브 탠치를 검 증하고 master 브 랜치로 Merge 할 때마다 토픽 브 탠치를 

삭제 한다. 그림 5—1 9 처럼 ruby— client 브 탠치와 php— client 브 탠치가 있을 때 ruby— client 브 탠치를 

master 브 탠치로 Merge 한 후 php— client 브 탠치를 Merge 하면 그림 5-20 과 같아 진다: 




php— client 



그림 5. 19: 저장 소의두 브랜치 



master 




php_client 



그림 5.20: Merge 한후의 저장소 

132 



Scott Chacon Pro Git 



,. 3 절 프로 젝트운 영하기 



이 Workflow 은 간단하 지만, 프로 젝트의 규모가 커지면 문제가 생길 수 있다. 
개 발자가 많고 규 모가큰 프 로젝트 에서는 두 단게로 Merge 하는 것이 좋다. 그래서 Long-Running 
브 탠치를 두 개로 유 지해야 한다. master 브 랜치는 아주 안 정격인 버전을 릴리 즈하기 위해서 사용한 
다. develop 브랜치 는새로 수정된 코드를 통합할 때사용 한다. 그리 고두브 탠치를 모두저 장소에 
Push 한다. 우선 develop 브 랜치에 토픽 브탠치 (그림 5-21) 를그림 5—22 과같이 Merge 한다. 그후 
에 릴리 즈해도 될만한 수준이 되면 master 브 탠치를 develop 브탠 치까지 Fast-forward 시킨다 (그 
림 5-23). 




그림 5.21 ： 토픽 브 랜치를 Merge 하기 전 




ruby_client 



그림 5.22: 토픽 브 랜치를 Merge 한후 

이 Workflow 을사 용하면 프로 젝트저 장소를 Clone 하고 나서 개발자 가안정 버전이 필 요하면 master 
브 랜치를 빌 드하고 안정 적이지 않 더라도 좀 더 초 I 신 버전이 필 요하면 develop 브 탠치를 Checkout 하 
여 빌드 한다. 이 개념을 좀 더 확 장해서 사용할 수 있다. 토픽 브 랜치를 검 증하기 위한 integrate 브랜 
치를 만들어 Merge 하고 토픽 브 탠치가 검 증되면 develop 브 랜치에 머지 한다. 그리고 develop 브탠 
치에서 충분히 안정 하다는 것이 증 명되면 그때 master 브 랜치에 Merge 한다. 

대규모 Merge Workflow 

Git 을 개 발하는 프로 젝트는 Long-Running 의 브 탠치를 4 개 운영 한다. 각 브탠치 이름은 master, 
next, pu (Proposed Updates), maint 이다. maint 는 마지 막으로 릴 리즈한 버견을 지 원하는 브랜 
치다. 기 여자가 새로운 기 능을제 안하면 관리자 는그림 5—24 처럼 자신의 저 장소에 토픽 브 탠치를 만 
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-| Cl j-*— ^ C2 j-< C5 j 





그림 5.23: 토픽 브 랜치를 릴리 즈한후 

들어 관리 한다. 그리고 토픽에 부족 한점은 없 는지， 안정 격인지 계속 테스트 한다. 안정 화되면 next 로 
Merge 하고 저 장소에 Push 한다. 그러면 모두가 잘 통합 됐는지 확인할 수 있다. 




그림 5.24: 토픽 브 랜치를 동시에 여러 개 관 리하는 것은 복 잡하다 

토픽 브탠치 가좀더 개 선돼야 하면 next 가 아니라 pu 에 Merge 한다. 그 후에 충분히 검증을 마치면 
pu 에서 next 로 옮기고 next 를기 반으로 pu 를 다시 만 든다. next 에는 아직 master 에 넣기에 모자라 
보이는 것들이 들어 있다. 즉 next 브 탠치는 정말 가끔 Rebase 하고 pu 는 자주 Rebase 하지만 master 
는항상 Fast-forward 한다 (그림 5-25). 



—Go 




{ C13 )<-(cl4 )<-fcIT)'«— j~ 



그림 5.25: 토픽 브 랜치를 Long-Running 브 랜치로 Merge 하기 



토픽 브 랜치가 결국 master 브 탠치로 Merge 되면 저장 소에서 삭제 한다. 그리고 이견 릴리즈 버견에 
Patch 가필 요하면 maint 브 랜치를 이용해 대응 한다. Git 을 개발하 는프로 젝트를 Clone 하면 브 랜치가 
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4 개 있고 각 브 탠치를 이 용하여 진행 사항을 확 인해볼 수 있다. 그래서 새로운 기능을 추가 하려면 격당 
한 브 랜치를 보고 고 른다. 이 Workflow 는 잘 구 조화돼 있어서 코드가 새로 추 가돼도 테스 트하기 쉽다. 



Rebas^ Cherry- Pick Workflow 

히스 토리를 평 평하게 관리 하려고 Merge 보다 Rebase 나 Cherry-Pick 을 더 선 호하는 관리 자들도 있 
다. 토픽 브탠 치에서 작업을 마친 후 master 에 통합할 때 master 브 탠치를 기 반으로 Rebase 한다. 
그러면 커밋이 다시 만들어 진다. master 대신 develop 등의 브탠 치에도 가능 하다. 문제가 없으면 
master 브 탠치를 Fast-forward 시 킨다. 이렇게 평평한 히스 토리를 유지할 수 있다. 
한 브탠 치에서 다른 브 탠치로 작업한 내용을 옮기는 또 다른 방 식으로 Cherry-pick 이란 것도 있다. 
Git 의 Cherry-pick 은 커밋 하나만 Rebase 하는 것 이다. 커밋 하나로 Patch 내용을 만들어 현재 브랜 
치에 격용을 하는 것 이다. 토픽 브 랜치에 있는 커밋 중에서 하나만 고 르거나 토픽 브 탠치에 커밋이 하나 
밖에 없을때 Rebase 보 다유용 하다. 그림 5-26 의 예 를들어 보자. 



master 



째- 



{ 0b743 》 * ᅳ ^ a6b4c^-< f42c5 ) 

J-^— ^ 5ddae ) 




e43a6 



ruby_client 



그림 5.26: Cherry-pick 을실 행하기 전의 저장소 

e43a6 커밋 하나만 현재 브 탠치에 격용 하려면 아래와 같은 명렁을 실행 한다: 



$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf 
Finished one cherry-pick. 

[master] ： created a0a41a9: "More friendly message when locking the index fails . 
3 files changed, 17 insertions(+) / 3 deletions(-) 



위 명령을 실 행하면 e43a6 커 밋에서 변경된 내용을 현계 브 탠치에 똑같이 적용을 한다. 하 지만， 변경 
을 격용한 시점이 다르 므로새 커밋의 SHA-1 해시 값 은달라 진다. 명령을 실행하 고나면 그림 5-27 과 
같 이될것 이다. 

Rebase 나 Cherry-pick 방 식으로 토픽 브 탠치를 합치고 나면 필 요없는 토픽 브 탠치나 커밋은 삭제한 
다. 



5.3.6 럴 리즈버 전에태 그달기 

적당한 때가 되면 릴리 즈해야 한다. 그리고 언 제든지 그 시 점으로 되돌릴 수 있게 태그를 다는 것이 좋 
다. 2 장에서 살펴본 대로 태그를 달면 된다. 서명된 태그를 달면 아래와 같이 출력 된다: 
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master 



i 




ruby_client 



그림 5.27: Cherry-pick 방 식으로 커밋 하나를 적용한 후의 저장소 



$ git tag -s v1 . 5 -m 'my signed 1.5 tag 1 
You need a passphrase to unlock the secret key for 
user: "Scott Chacon <schacon@gmail.coin>" 
1024-bit DSA key, ID F721C45A, created 2009-02-09 

태그에 서 명하면 서명에 사용한 PGP 공 개키도 배 포해야 한다. Git 개발 프로 젝트는 관 리자의 PGP 공 
개키를 Blob 형 식으로 Git 저 장소에 함께 배포 한다. 이 Blob 파일을 사 용하여 태그에 서명 했다. 아래와 
같은 명 렁으로 어떤 PGP 공 개키를 포 함할지 확인 한다: 

$ gpg ―— list-keys 

/Users/ schacon/ . gnupg/pubring . gpg 



pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09] 
uid Scott Chacon <schacon@gmail . com) 

sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09] 

git hash-object 라는명 렁으로 공개키 를바로 Git 저 장소에 넣을수 있다. 이 명렁은 Git 저장 소안에 
Blob 형 식으로 공 개키를 저장 해주고 그 Blob 의 SHA-1 값을 알려 준다: 

$ gpg -a ― export F721C45A ！ git hash-object — w ― stdin 
659ef797d181 633c87ec71 ac3f9ba29fe5775b92 

이 SHA-1 해시 값으로 PGP 공개키 를가리 키는태 그를만 든다: 

$ git tag -a maintainer-pgp-pub 659ef 797d1 81 633c87ec71 ac3f 9ba29f e5775b92 
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git push -tags 명령으 로앞서 만든 maintainer-pgp_pub 태그 를공유 한다. 다른 사람이 태 그의서 
명 을확인 하려면 우선 Git 저 장소에 저장된 PGP 공 개키를 꺼내서 GPG 키 데 이터베 이스에 저장 해야한 
다: 



$ git show maintainer-pgp-pub ！ gpg ―— import 



사 람들은 이렇게 공 개키를 얻어서 서명된 태그 를확인 한다. 또한, 관 리자가 태그 메 시지에 서명 을확인 

하는 방법을 격어 놓으면 좋다. git show <^ 9 >으로 어떻게 서명된 태그를 확인 하는지 설명 한다. 
5.3.7 빌 드넘버 만들기 

Git 은 VI 23' 처럼 숫자 형태로 커밋 이름을 만들지 않기 때문에 사람이 기 억하기 어 렵다. 하지만 git 
describe 명 렁으로 좀 더 사람이 기 억하기 쉬운 이름을 얻을 수 있다. Git 은 가장 가까운 태그의 이 름과， 
태 그에서 얼 마나더 커밋이 쌓였 는지， 그리 고해당 커밋의 SHA-1 값을조 금가겨 다가이 름을만 든다: 

$ git describe master 
v1 .6.2-rc1-20-g8c5b85c 



이렇게 사람이 읽을 수 있는 이 름으로 스냅 샷이나 빌드를 만 든다. 만약 저장 소에서 Clone 한 후 소스코 

드로 Git 을 설 치하면 git -version 명렁은 이렇게 생긴 빌드 넘버를 보여 준다. 태그가 달린 커밋에 git 
describe 명 렁을사 용하면 다른정 보없이 태 그이름 만사용 한다. 

git describe 명령은 -a 나 -s 옵 션을주 고만든 Annotated 태그 가필요 하다. 릴리즈 태그는 git 
describe 명 령으로 만드 니까꼭 이름이 적 당한지 사견에 확 인해야 한다. 그리고 이 값은 Checkout 이나 
Show 명 령에도 사용할 수 있지 만, 견 격으로 이름 뒤에 붙은 SHA-1 값을 사용 한다. 그래서 이 값으로 
는 해당 커밋을 못 찾을 수도 있다. 최근 Linux Kernel 은 충돌 때문에 축약된 SHA—1 를 8 자에서 1 0 자 
로 늘 렀다. 이제는 8 자일 때 생성한 값은 사용할 수 없다. 

5.3.8 럴 리즈준 비하기 

먼저 Git 을 사 용하지 않는 사람을 위해 소 스코드 스 냅샷을 압축 한다. 쉽게 압축할 수 있도록 Git 은 git 
archive 명령 을지원 한다: 

$ git archive master —prefix=' project/ ' ！ gzip > "git describe master" .tar.gz 
$ Is *. tar.gz 

v1 . 6 . 2-rc 1 -20-g8c5b85c . tar . gz 



이 압축 파일을 풀면 프로 젝트의 가장 마지막 스 냅샷이 나 온다. ZIP 형 식으로 압축 파일을 만 들려면 -- 

format=zip 옵션 을사용 한다: 



$ git archive master —prefix=' project/ ' — format=zip > "git describe master" .zip 



이렇게 압축한 스냅샷 파일은 Website 나 이 메일로 사람 들에게 배포할 수 있다. 
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5.3.9 Shortlog 보기 

이메일 로프로 젝트의 변경 사항 을사람 들에게 알려야 할때， git shortlog 명 령을사 용하면 지 난릴리 
즈이 후의변 경사항 목록을 쉽게얻 어을수 있다. git shortlog 명 렁은주 어진범 위에있 는커밋 을요약 
해 준다. 아래 는최근 릴리즈 버견인 V1. 0.1 이 후의커 밋을요 약해주 는예제 이다: 



$ git shortlog ―— no-merges master ―— not v1 .0. 1 
Chris Wanstrath (8)： 

Add support for annotated tags to Grit: :Tag 

Add packed— refs annotated tag support. 

Add Grit: :Cc)mmit#to_pa1:ch 

Update version and History.txt 

Remove stray "puts" 

Make Is— tree ignore nils 



Tom Preston-Werner (4): 

fix dates in history 

dynamic version method 

Version bump to 1.0.2 

Regenerated gemspec for version 1.0. 



이렇게 Author 를 기 준으로 정리한 커 밋을이 메일로 전송 한다. 



5.4 요약 

이제 Git 프로 젝트에 기여 하고, 자신의 프로 젝트를 운영 하고， 다른 사람이 기여한 내용을 통 합하는 것 
정도는 쉽게 할 수 있을 것 이다. 일단 쓸만한 Git 개 발자가 된 것을 축하 한다. 다음 장에서 복잡한 상황 
을 다루는 방법과 강력한 도 구들을 배우고 나면 Git 장인 이라고 불릴 수 있을 것 이다. 
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지 금까지 일상 격으로 자주 사 용하는 명렁 어들과 S 가지 Workflow 를 배 웠다. 파일을 추 격하고 커밋 
하 는등의 기 본적인 명령 어뿐만 아니라 Staging Area 가왜 좋 은지도 배웠고 가볍게 토픽 브 랜치를 만 
들고 Merge 하는 방법도 다 뤘다. 이제는 소 스코드 관리를 Git 저 장소로 충분히 해낼 수 있을 것 이다. 
이 장 에서는 일상 격으로 사용 하지는 않지만 위급한 상 황에서 반드시 필요한 Git 도구를 살펴 본다. 



6.1 리 비전조 회하기 

리비견 하나를 조회할 수도 있고 범위를 주고 여러 개를 조회할 수도 있다. 잘 쓰진 않지만 알아 두는게 
좋다. 

6.1.1 리비전 하나가 리키기 

사람은 커밋을 나 타내는 SHA-1 해시 값을 쉽게 기억할 수 없다. 이 결 에서는 커밋을 표 현하는 방법을 
몇 가지 설명 한다. 좀 더 사람이 기 억하기 쉬운 방법들 이다. 

6.1.2 짧은 SHA-1 

해시 값의 앞 몇 글차 만으로 도어떤 커 밋인지 충분히 식별할 수 있다. 중 복되지 않으면 해시 값의 앞 4 
자만사 용해도 된다. 유일 하기만 하면 짧은 SHA-1 값 이라도 괜 찮다. 
먼저 git log 명령으 로어떤 커밋이 있는지 조회 한다: 



$ git log 

commit 73471 3bc047d87bf7eac9674765ae793478c50d3 
Author: Scott Chacon 〈schacon@gmail.com〉 
Date: Fri 3an 2 18:32:33 2009 -0800 

fixed refs handling, added gc auto, updated tests 

commit d921 970aadf03b3cf0e71 becdaab31 47ba71 cdef 
Merge: 1c002dd... 35cfb2b... 
Author: Scott Chacon 〈schacon@gmail.com〉 
Date: Thu Dec 11 15:08:43 2008 -0800 
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Merge commit 1 phedders/rdocs 1 

commit 1 C002dd4b536e7479fe34593e72e6c6c 1 81 9e53b 
Author: Scott Chacon 〈schacon@gmail.com〉 
Date: Thu Dec 11 14:58:32 2008 -0800 

added some blame and merge stuff 



git show 명 렁으로 1c002dd. , . . 로시 작하는 커밋을 조희 한다면 아래와 같이 조회 할 수 있다ᅳ 다음 명렁 
어는모 두같다 (단짧 은해시 값이 다른커 밋과중 복되지 않다고 가정) ： 

$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b 
$ git show 1c002dd4b536e7479f 
$ git show 1c002d 



git log 명 렁어에 -abbrev-comniit 옵션을 추 가하면 짧은 해시 값을 보여 준다. 기 본으로 7 자를 보여주 
고 해시 값이 중 복되면 더 긴 해시 값을 보여 준다: 

$ git log —abbrev— commit ―— pretty=oneline 
ca82a6d changed the version number 
085bb3b removed unnecessary test code 
a11bef0 first commit 



보통은 8 자에서 10 자 내외로 도충분 하다. 이 정도 로도중 복되지 않 는다. 대규 모프로 젝트인 리 눅스커 
널도 커밋을 가리 키는데 해시 값 40 자 중에서 1 2 자만 사용 한다. 

6.1.3 SHA-1 해시 값에 대한 단상 

Git 을쓰 는사람 중에서 가 능성이 낮긴 하지만 언젠가 SHA—1 값이 중복될 까봐걱 정하는 사람도 있다. 
정말 그렇게 되면 어떤 일이 벌어 질까? 

이미 있는 SHA-1 값을 Git 데 이터베 이스에 커밋하 면새로 운개체 라고해 도이미 커밋 한것으 로간주 
된다. 그래서 해당 SHA-1 값의 커밋을 Checkout 하면 항상 처음에 저장한 커밋만 Checkout 된다. 
그러 나 해시 값 0 1 중 복되는 일은일 어나기 어렵다 . SHA- 1 값의 크기는 20 바이트 ( 1 60 비트) 이 다. 
해시 값이 중복될 확를이 50% 가 되는 데 필요한 개체의 수는 2 80 이다. 이 수는 1 .2 자 ('자 '는 '경' 의 

'억' 배 -10824) 이다 (충돌 확룰을 구하는 공식은 p=( n (n-1)/2) * (1/2H160) 이다 ). 즉, 지 구에존 재하는 

모 래알의 수에 1 200 을 곱한 수와 맞먹 는다. 

아직도 SHA-1 해시 값이 중복 될까봐 걱정 하는사 람들을 위해 좀 더 덧붙이 겠다. 지 구에서 약 6.5 억 
명의 인구가 개 발하고 각자 매초 리눅스 커널 히 스토리 전체와 (1 00 만 개) 맞먹는 개체를 쏟아 내고 바 
로 Push 한다고 가정 하자. 이런 상 황에서 해시 값의 충돌 날 확률이 50% 가 되기 까지는 5 년이 걸 린다. 
그낭 어느 날 동료가 전부 한 순간에 늑 대에게 물려 죽을 확를이 «썬 더 높다. 
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6.1.4 브랜 치로가 리키기 

브탠 치를사 용하는 것이커 밋을나 타내는 가장쉬 운방법 이다. 커밋 개체나 SHA-1 값 이필요 한곳이 
면 브탠치 이름을 사용할 수 있다. 만약 topid 브 탠치의 최근 커밋을 보고 싶으면 아래와 같이 실행한 
다. topic! 브 탠치가 ca82a6d 를가 리키고 있기 때문에 두 명령의 결과는 갈다: 



$ git show Ca82a6dff817ec66f44342007202690a93763949 
$ git show topid 



브 랜치가 가 리키는 개체의 SHA—1 값에 대한 궁 금증은 rev-parse 이라는 Plumbing 도구가 해결해 준 
다. 9 장에서 이 도구에 대해 좀 더 자세히 설명 한다. 기본 격으로 rev-parse 은 겨수준 명령 어이기 때문에 
평 소에는 전혀 필 요하지 않지만 그래도 한번 사용 해보고 어떤 결과가 나 오는지 알아 두자: 



$ git rev-parse topid 
Ca82a6dff817ec66f44342007202690a93763949 



6.1.5 RefLog 로가 리키기 

Git 은 자 동으로 브 탠치와 HEAD 가 지난 S 달 동안에 가리 컸었던 커밋을 모두 기록 하는데 이 로그를 
Reflog 라고부 른다. 

git reflog 를실 행하면 Reflog 를볼수 있다: 



$ git reflog 
734713b HEAD@{0} 
d921970 HEAD@{1} 
1c002dd HEAD@{2} 
1C36188 HEAD@{3} 
95df984 HEAD@{4} 
1C36188 HEAD@{5} 
7e05da5 HEAD@{6} 



commit: fixed refs handling, added gc auto, updated 

merge phedders/rdocs: Merge made by recursive. 

commit: added some blame and merge stuff 

rebase -i (squash): updating HEAD 

commit: # This is a combination of two commits. 

rebase -i (squash): updating HEAD 

rebase -i (pick) ： updating HEAD 



Git 은브 랜치가 가리키 는것이 변경될 때마다 그정보 를임시 영역 에겨장 한다. 그래서 예견에 뭘가리 
켰 었는지 확인할 수 있다. @{n} 규칙을 사 용하면 아래와 같이 HEAD 가 5 번 전에 가 리켰던 것을 알수있 
다: 



$ git show HEAD®{5} 



순서뿐 아니라 시간도 가능 하다. 어제 날짜의 master 브 랜치를 보고 싶으면 아래와 같이 한다: 
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이 명령 은어제 master 브 랜치가 가리키 고있던 것이 무 엇인지 보여 준다. Reflog 에 남 아있는 것만조 
회할 수 있기 때문에 너무 오래된 커밋은 조회할 수 없다. 

git log -g 명 렁을사 용하면 git reflog 결과를 git log 명 령과같 은형태 로볼수 있다: 

$ git log -g master 

commit 73471 3bc047d87bf7eac9674765ae793478c50d3 

Reflog: master@{0} (Scott Chacon <schacon@gmail . com>) 

Reflog message: commit: fixed refs handling, added gc auto, updated 

Author: Scott Chacon 〈schacon@gmail.com〉 

Date: Fri 3an 2 18:32:33 2009 -0800 

fixed refs handling, added gc auto, updated tests 

commit d921 970aadf03b3cf0e71 becdaab31 47ba71 cdef 

Reflog: master@{1 } (Scott Chacon <schacon@gmail . com>) 

Reflog message: merge phedders/rdocs: Merge made by recursive. 

Author: Scott Chacon 〈schacon@gmail.com〉 

Date: Thu Dec 11 15:08:43 2008 -0800 



Merge commit 1 phedders/rdocs 




reflog 의 일 은모두 로컬의 일이기 때문에 내 reflog 가동료 의저장 소에는 있을수 없다. 이제 막 Clone 

한저장 소에도 아무것 도한게 없어서 reflog 가 하나도 없다. git show HEAD@{2. months. ago} 같 은명렁 

은격 어도두 달견에 Clone 한저 장소에 서나사 용할수 있다. 그러 니까이 명렁을 5 분전에 Clone 한저 
장소에 사 용하면 아 무것도 나오지 않 는다. 

6.1.6 계통관 계로가 리키기 

게통 관 계로도 커밋을 표현할 수 있다. 이름 끝에 K 를 붙이면 Git 은 해당 커밋의 부모를 찾 는다. 프로젝 

트 히스토 리가아 래와같 을때: 

$ git log — pretty=format: '%h %s 1 —― graph 

* 734713b fixed refs handling, added gc auto, updated tests 

* d921970 Merge commit 1 phedders/rdocs 1 
!\ 

！ ★ 35cfb2b Some rdoc changes 

* ！ 1c002dd added some blame and merge stuff 
！/ 

* 1c36188 ignore *.gem 

* 9b29157 add open3— detach to gemspec file list 
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head§ 는바로 "HEAD 의 부모" 를 의미 하으로 바로 이견 커밋을 보여 준다: 

$ git show HEAD A 

commit d921 970aadf03b3cf0e71 becdaab31 47ba71 cdef 
Merge: 1c002dd... 35cfb2b... 
Author: Scott Chacon 〈schacon@gmail.com〉 
Date: Thu Dec 11 15:08:43 2008 -0800 

Merge commit 1 phedders/rdocs 1 



l 뒤에 숫자도 사용할 수 있다. 예를 들어 d92i97W 는 "d921 970 의 두 번째 부모" 를 의미 하기에 두 번 
째 부모가 있는 Merge 커 밋에만 사용할 수 있다. 첫 번째 부모는 Merge 할 때 Checkout 했던 브탠치 
를 말하고 두 번째 부모는 Merge 한 대상 브 탠치를 의미 한다. 

$ git show d921970 A 

commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b 
Author: Scott Chacon 〈schacon@gmail.com〉 
Date: Thu Dec 11 14:58:32 2008 -0800 

added some blame and merge stuff 

$ git show d921970 A 2 

commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548 
Author: Paul Hedderly <paul+git@mj r . org> 
Date: Wed Dec 10 22:22:03 2008 +0000 

Some rdoc changes 



게통을 표 현하는 방 법으로 〜라는 것도 있다. HEAD 〜와 HEADi 는 똑같이 첫 번째 부모를 가리 킨다. 하지만 
그 뒤에 숫자를 사 용하면 달라 진다. ^은[)~2는 명렁을 실행할 시점의 "첫 번째 부모의 첫 번째 부 모"， 즉 
"조 부모" 를 가리 킨다. 위의 예 제에서 ^[)〜3은 아래와 같다: 

$ git show HEAD〜3 

commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d 
Author: Tom Preston-Werner <tom@mo jombo.com> 
Date: Fri Nov 7 13:47:59 2008 -0500 

ignore *.gem 
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이 것은 HEADBffl 와 같은 표현 이다. 다시 말해서 첫 번째 부모의 첫 번째 부모의 첫 번째 부모를 말 한다: 



$ git show HEAD AAA 

commit 1 c361 8887af b5f bcbea25b7c01 3f 4e21 1 4448b8d 
Author: Tom Preston-Werner <tomimojombo.coiin> 
Date: Fri Nov 7 13:47:59 2008 -0500 

ignore *.gem 



이 두 표현을 같이 사용할 수도 있다. 위의 예 제에서 head~»2 를 사 용하면 증조 부모의 Merge 커밋의 
두번 째부모 를조회 한다. 

6.1.7 범위로 커밋가 리키기 

커밋을 하나씩 조회할 수도 있 지만, 범위를 주 고여러 커밋을 한 끼번에 조회할 수도 있다. 범위을 주고 
조 회하면 브탠 치를관 리할때 유용 하다. 브 탠치가 상당히 많고 "왜 아직 도주브 랜치에 Merge 가안된 
브랜 치들은 무엇에 대한브 랜치일 까?" 라는 의문이 들면 범위를 주고어 떤브랜 치인지 쉽게 알 아볼수 
있다. 

Double Dot 

범위를 표 현하는 문 법으로 Double DotC.) 을 많이 쓴다. Double Dot 은 한 쪽에는 있고 다른 쪽에는 
없는 커밋이 무 엇인지 Git 에게 물 어보는 것 이다. 예 들들어 그림 6-1 과 같은 커밋 히스 토리가 있다고 
가정 하자. 



CZMZHZH3H 




그림 6.1 ： 범위를 설 명하는 데 사용할 예제 

experiment 브 탠치의 커밋들 중에서 아직 master 브 탠치에 Merge 하지 않은 것만 보고 싶으면 
master, .experiment 라 고사용 한다. 이 표현은 "master 에는 없 지만， experiment 에는 있는 커밋" 을 의 
미 한다. 여기 에서는 설명을 쉽게 하고자 실제 조회 결과가 아니라 그림 6-1 의 문자 를사용 한다: 



$ git log master. .experiment 
D 



반대로 experiment 에는 없고 master 에만 있는 커밋이 긍 금하면 브탠치 순서를 거꾸로 사용 한다. 

experiment, .master 는 experiment 에는 없고 master 에만 있는 것을 알려 준다: 
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6.1 절 리 비견조 회하기 



$ git log experiment. .master 



experiment 브 랜치를 Merge 하기 건에 무엇이 변경 됐는지 긍금 하다. 그리고 리모트 저 장소에 Push 할 

때에도 마 찬가지 로차이 가궁금 하다. 이렇게 궁 금한상 황에서 굉장히 유용 하다: 



$ git log origin/master. .HEAD 



이 명렁은 origin 저 장소의 master 브탠 치에는 없고 현개 Checkout 중인 브탠 치에만 있는 커밋을 보 
여 준다. Checkout 한브 탠치가 origin/master 라면 git log origin/master. .HEAD 가보 여주는 커밋이 
Push 하면 서버에 전송될 커밋 이다. 그리고 한쪽의 레퍼런 스를생 락하면 Git 은 HEAD 라 고가정 한다. 

git log origin/master. . 는 git log origin/master. .HEAD 와같 다. 

세개이 상의레 퍼런스 

Double Dot 은 간 단하고 유용 하다. 하 지만, 두 개 이상의 브랜 치에는 사용할 수 없다. 그 러니까 현개 
작업 중인 브탠 치에는 있지만 다튼 여러 브탠 치에는 없는 커밋이 보고 싶으면 . . 으로는 확인할 수 없다. 
3 과 - no t 옵션 뒤에 브랜치 이름을 넣으면 그 브 탠치에 없는 커밋을 찾아 준다. 다음 명 령어는 모두 같은 

명령 이다: 

$ git log refA. .refB 
$ git log A refA refB 
$ git log refB —not refA 



Double Dot 으로는 세 개 이상의 레퍼 런스에 사용할 수 없지만 이 옵션은 가능 하다. 예를 들어 refA 나 
refB 에는 있지 만 ref C 에는 없는 커 밋을 보려면 다음 중 하나를 사용 한다: 



$ git log refA refB A refC 

$ git log refA refB ―— not refC 




이 조건을 잘 응 용하면 작업 중인 브 랜치와 다른 브 랜치를 매우 상 세하게 비교할 수 있다. 



Triple Dot 

Triple Dot 은 양쪽에 있는 두 레 퍼런스 사 이에서 공 통으로 가지는 것을 제 외하고 서로 다른 커밋만 보 
여 준다. 그림 6_ 1 의커밋 히스 토리를 다시 보자. 만약 master 와 experiment 의 공통 부분은 빼고 다른 커 
밋만 보고 싶으면 아래와 같이 하면 된다: 
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$ git log master. . .experiment 



D 



우리가 아는 log 명렁의 결 고ᅡ를 최근 날짜 순으로 보여 준다. 이 예제 에서는 커밋을 네 개 보여 준다. 
그리고 log 명렁에 -left-right 옵션을 추 가하면 각 커밋이 어느 브 랜치에 속하 는지도 보 여주기 때문 
에 좀더이 해하기 쉽다: 



$ git log —― left-right master. . .experiment 

< F 

< E 

> D 

> C 



위와 같은 명 렁들을 사 용하면 원하는 커밋을 좀 더 꼼 꼼하게 살펴볼 수 있다. 

6.2 대화형 명렁어 

Git 은 대화형 명 렁어도 제 공해서 좀 더 쉽게 사용할 수 있다. 여기서 소 개하는 몇 가지 대화형 명 령어를 
이 용하면 바로 견문 가처럼 능 숙하게 커밋할 수 있다. 대화 형으로 커밋할 파일을 고를 수도 있고 수정 
된 파일의 일 부분만 커밋할 수도 있다. 수정한 파일이 매우 많고 통째로 커 밋하지 않고 이슈 별로 나눠 
서 커밋할 때 유용 하다. 이슈 별로 나눠서 커 밋하면 동료가 쉽게 검토할 수 있다. git add 명렁에 -i 나 -- 
interactive 옵션을 주고 실 행하면 Git 은 아래와 같은 대화형 모드로 들어 간다: 



$ git add — i 




staged 


unstaged path 


1 ： unchanged 


+0/-1 TODO 


2： unchanged 


+1/-1 index.html 


3： unchanged 


+5/-1 lib/simplegit.rb 


Commands 




1: starts 2： 


update 3： revert 4： add untracked 


5： patch 6： 


diff 7： quit 8： help 


What now> 





이 명 령어는 Staging Area 의 현계 상태가 어떻고 할 수 있는 일이 무 엇인지 보여 준다. 기본 적으로 git 
status 명령이 보 여주는 것과 같지만 좀 더 간 결하고 정돈돼 있다. 왼 쪽에는 Staged 상태인 파 일들을 
보 여주고 오른 쪽에는 Unstaged 인 파 일들을 보여 준다. 
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그리고 마지막 Comman ds 부분 에서는 할 수 일이 무 엇인지 보여 준다. 파일을 Stage 하고 Unstage 하는 
것， Untracked 상태의 파일을 추 가하는 것， Stage 한 파일을 diff 해보는 것을 할 수 있다. 게다가 수정 
한 파일의 일 부분만 Staging Area 에 추가할 수도 있다. 



6.2. 1 Staging Area 에 파일 추 가하고 추가 취 소하기 

what now> 프롬프 트에서 2 나 u 를 (update) 입 력하면 Staging Area 에 추가할 수있는 파일을 견부보 
여 준다: 



What now> 2 




staged 


unstaged path 


1 ： unchanged 


+0/-1 TODO 


2： unchanged 


+1/-1 index.html 


3： unchanged 


+5/-1 lib/simplegit.rb 


Update)) 





TODO 오 f index.html 파일을 Stage 하려면 아래와 같이 입력 한다: 



Update)) 1 





staged 


unstaged path 


* 1： 


unchanged 


+0/-1 TODO 




unchanged 


+1/-1 index.html 




unchanged 


+5/-1 lib/simplegit.rb 



Update)) 




* 표시 가붙은 파일은 stage 하 도록선 택한것 이다. 선 택하고 u P date》 프롬 프트에 아무 것도입 력하지 
않고 엔터를 치면 Git 은 선택한 파일을 Staging Area 로 추가 한다: 



Update)) 




updated 2 paths 




Commands 




1: status 2: 


update 3： revert 4： add untracked 


5： patch 6： 


diff 7： quit 8： help 


What now) 1 




staged 


unstaged path 


1 ： +0/-1 


nothing TODO 


2: +1/-1 


nothing index.html 


3： unchanged 


+5/-1 lib/simplegit.rb 



이제 TODO 오 F index.html 파일은 Stage 했고 simplegit.rb 파일만 아직 Unstaged 상태로 남아 있 
다. 이제 TODO 파일을 다시 Unstage 하고 싶으면 3 이나 r 을 (Revert) 입력 한다: 
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Commands 
1: sterns 2: 
5： patch 6： 
What now) 3 

staged 
1 : +0/-1 
+1/-1 
unchanged 
Revert» 1 

staged 
* 1： +0/-1 
+1/-1 
unchanged 
Revert» [enter] 
reverted one path 



update 3： revert 4： add untracked 
diff 7： quit 8： help 

unstaged path 
nothing TODO 
nothing index.html 
+5/-1 lib/simplegit.rb 

unstaged path 
nothing TODO 
nothing index.html 
+5/-1 lib/simplegit.rb 



다시 Status 를선 택하면 TODO 파일이 Unstaged 상태인 것을 알 수 있다: 



Commands 
1 ： status 2: update 
5： patch 6： diff 
What now) 1 

staged 



3： revert 
7： quit 



1 



4: add untracked 
8： help 



unstaged path 
unchanged +0/-1 TODO 

1 nothing index.html 
unchanged +5/-1 lib/simplegit.rb 



Staged 파일의 변경 내용을 보려면 6 이나 d 를 (diff) 입력 한다. 그러면 먼저 Staged 상태인 파 일을보 

여 준다. 그리고 그 중에서 파일 하나를 선택 한다. 그 결과는 명렁 줄에서 git diff -cached 라고 실행한 

결과와 같다: 



Commands 

1: status 2： update 3： revert 
5： patch 6： diff 7： quit 

What now) 6 

staged unstaged path 
1: +1/-1 nothing index.html 

Review diff» 1 

diff —git a/index. html b/index.html 
index 4d07108. .4335f49 100644 
— a/index. html 



4: add untracked 
8： help 
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+++ b/index.html 

@@ -16,7 +16,7 @@ Date Finder 

<p id="out"〉. . .</p> 

-<div id="footer">contact ： support@github.com</div> 
+<div id="footer">contact : email .support@github.com</div> 



<script type=" text/ javascript "> 




대화형 모드를 사 용하면 Staging Area 에 파일을 좀 더 쉽게 추가할 수 있다. 
6.2.2 파일의 일 부분만 Staging Area 에 추 가하기 

파일의 일 부분만 Staging Area 에 추 가하는 것도 가능 하다. 예를 들어 simplegit.rb 파일은 고친 부분 
이 두 군데 이다. 그 중 하나를 추 가하고 나 머지는 그대로 두고 싶다. Git 에서는 이런 작업도 매우 쉽게 
할수 있다. 대화형 프롬프 트에서 5, p 를 (patch) 입력 한다. 그러면 Git 은부분 격으로 Staging Area 에 
추가할 파일이 있는지 묻 는다. 파 일을선 택하면 파일의 특정 부분을 Staging Area 에 추가할 것인지 부 
분별 로구분 하여묻 는다: 



diff —git a/lib/simplegit.rb b/lib/simplegit.rb 


index dd5ecc4. . 57399e0 


100644 




— a/lib/simplegit.rb 






+++ b/lib/simplegit.rb 






@@ —22,7 +22,7 @@ class 


SimpleGit 




end 






def log(treeish = 'master' ) 




- command( "git log - 


n 25 #{tree 


ish}") 


+ command( "git log - 


n 30 #{treeish}") 


end 






def blame(path) 






Stage this hunk [y^n^a, 


d,/,j, ] ,g,e 


, ？]? 



여 기에서 ？를입 력하면 선택 가능한 명 령어를 설명해 준다: 



Stage this hunk [y 세 Hg,e/?]7 ？ 

y - stage this hunk 

n - do not stage this hunk 

a - stage this and all the remaining hunks in the file 

d - do not stage this hunk nor any of the remaining hunks in the file 
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g - select a hunk to go to 

I - search for a hunk matching the given regex 

j - leave this hunk undecided, see next undecided hunk 

G - leave this hunk undecided, see next hunk 

k - leave this hunk undecided, see previous undecided hunk 

K - leave this hunk undecided, see previous hunk 

s - split the current hunk into smaller hunks 

e - manually edit the current hunk 



- print help 




y 나 0을 입 력하면 각 부분을 Stage 할지 말지 결정할 수 있다. 하 지만, 파일을 통째로 stage 하거나 필 
요할 때까지 아예 그대로 남겨 두는 것이 다음에 더 유용 할지도 모 른다. 어쨌든 파일의 한 부분은 Stage 
하고 다른 부분은 unstaged 상태로 남 겨놓고 status 명 렁으로 확인 해보면 결과는 아래와 같다: 



What now) 1 




staged 


unstaged path 


1 ： unchanged 


+0/-1 TODO 


2: +1/-1 


nothing index.html 


3： +1/-1 


+4/— 0 lib/simplegit.rb 



simplegitrb 파일의 상태를 보자. 어떤 줄은 Staged 상 태이고 어떤 줄은 Unstaged 라고 알려줄 것 
이다. 이 파일은 부분 격으로 Stage 하 였다. 이제 대화형 모드를 종 료하고 일 부분만 Stage 한 파일을 커 
밋할수 있다. 

끝으 로대화 형스크 립트로 만파일 일 부분을 Stage 할 수있는 것은아 니다. git add -p 나 git add - 
patch 로도 같은일 을할수 있다. 



6.3 Stashing 

당신이 어떤 프로젝 트에서 한 부분을 담 당하고 있다고 하자. 그리고 여 기에서 뭔가 작 업하던 일이 있고 

다른 요청이 들 어와서 잠시 브 랜치를 변 경해야 할 일이 생 겼다고 치자. 아직 완 료하지 않은 일을 커밋하 
는 것은좀 껄고 립다. 이런 상황 에서는 커 밋하지 않고 나중에 다시 돌 아와서 작업을 다시 하고 심을 것 

이다. 이 문제는 git stash 라 는명령 으로해 결할수 있다. 

Stash 명 령을사 용하면 워킹 디텍토 리에서 수정한 파일만 저장 한다. Stash 는 Modified 이면서 
Tracked 상태인 파일과 Staging Area 에 있는 파 일들을 보관 해두는 장 소다. 아직 끝나지 않은 수정사 
항을 스택에 잠시 겨장 했다가 나중에 다시 적 용할수 있다. 

6.3.1 하 던일을 Stash 하기 

예제 프로 젝트를 하나 살펴 보자. 파일을 두 개 수 정하고 그 중 하나는 Staging Area 에 추가 한다. 그리 

고 git status 명렁을 실 행하면 아래와 갈은 결과를 볼 수 있다: 
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$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <f ile>. . . " to unstage) 

# 

# modified ： index . html 
# 

# Changes not staged for commit: 

# (use "git add <f ile>. . . " to update what will be committed) 

# 

# modified: lib/simplegit.rb 
# 

이제 브탠치 를변경 한다. 아 직작업 중인파 일은커 밋할게 아니라 서모두 Stash 한다. git stash 를실 

행하면 스택에 새로운 Stash 가 만들어 진다: 

$ git stash 

Saved working directory and index state \ 

"WIP on master: 049d078 added the index file" 
HEAD is now at 049d078 added the index file 
(To restore them type "git stash apply" ) 

대신워 킹디텍 토리는 깨끗해 겼다: 

$ git status 

# On branch master 

nothing to commit, working directory clean 



이제 아무브 탠치나 골라서 바꿀수 있다. 수정 하던것 은스택 에저장 했다. 아래 와같이 git stash 
list 를 사 용하여 저장한 Stash 를 확인 한다: 



$ git stash list 






stash@{0}: WIP on 


master: 


049d078 added the index file 


stash@{l}: WIP on 


master: 


C264051 Revert "added file— size" 


stash@{2}: WIP on 


master: 


21d80a5 added number to log 



Stash 두 개는 원래 있었던 것 이다. 그래서 현재 총 세 개의 Stash 를 사용할 수 있다. 이제 git stash 

apply 를사 용하여 Stash 를격 용할수 있다. git stash 명 령을실 행하면 이 명령에 대한 도움말 을보여 

주기 때문에 편리 하다. 다른 Stash 를 고르고 싶으면 Stash 이 름을입 력해야 한다. 이름이 없으면 Git 
은가장 최근의 Stash 를적용 한다: 
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$ git stash apply 

# On branch master 

# Changes not staged for commit: 

# (use "git add <f ile>. . . " to update what will be committed) 

# 

# modified: index.html 

# modified: lib/simplegit.rb 
# 



Git 은 Stash 에 저장할 때 수 정하던 파일을 복원해 준다. 복원할 때의 워킹 디텍 토리는 Stash 할 때의 
그 브탠 치이고 워킹 디롁 토리도 깨끗한 상태 였다. 하 지만, 꼭 깨끗한 워킹 디텍 토리나 Stash 할 때와 같 
은브 탠치에 적용해 야하는 것은아 니다. 어떤 브랜 치에서 Stash 하고 다 른브탠 치로옮 기고서 거기에 
Stash 를 복원할 수 있다. 그리고 꼭 워킹 디텍 토리가 깨끗한 상태일 필요도 없다. 워킹 디텍 토리에 수 
정 하고커 밋하지 않은파 일들이 있을 때에도 Stash 를격 용할수 있다. 만약 충돌이 나면 알려 준다. 
Git 은 Stash 를 격용할 때 Staged 상 태였던 파일을 자 동으로 다시 Staged 상태로 만들어 주지 않는 

다. 그래서 git stash apply 명렁을 실행할 때 —index 옵션을 주어야 Staged 상 태까지 복원 한다. 그럼 

원래 작 업하던 상태로 돌아올 수 있다: 



$ git stash apply —index 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <f ile>. . . " to unstage) 

# 

# modified ： index . html 

# 

# Changes not staged for commit: 

# (use "git add <f ile>. . . " to update what will be committed) 
# 

# modified: lib/simplegit.rb 
# 



apply 옵션은 단순히 Stash 를 격용하 는것뿐 이다. Stash 는여전 히스택 에남아 있다. git stash drop 

명 렁을사 용하여 해당 Stash 를제거 한다: 



$ git stash list 

stash@{0}: WIP on master: 049d078 added the index file 
stash@{l}: WIP on master: C264051 Revert "added file_size" 
stash@{2}: WIP on master: 21d80a5 added number to log 
$ git stash drop stash@{0} 

Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) 
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6.3 절 Stashing 



그리고 git stash pop 이 라는명 령도있 는데이 명렁은 Stash 를 격용하 고나서 바 로스택 에서제 거해준 
다. 



6.3.2 Stash 되 돌리기 

Stash 를 적 용하고 나서 아차 싶을 때에는 다시 되돌려 놓아야 한다. Git 은 stash unapply 같은 명렁을 

제공 하지는 않 는다. 하 지만, Stash 를 이 용해서 패치를 만들고 그것을 거꾸로 적용할 수 있다: 



$ git stash show — p stash@{0} ！ git apply -R 




Stash 를 명 시하지 않으면 Git 은 가장 최근의 Stash 를 사용 한다: 



$ git stash show — p ！ git apply — R 



stash-unapply 라는 alias 를 만들고 편 리하게 할 수도 있다: 



$ git config —global alias. stash— 니 napply 1 ！ git stash show — p ！ git apply — R 

$ git stash apply 
$ work work work 

$ git stash-unapply 



6.3.3 Stash 를 적용한 브랜치 만들기 

보통 Stash 에 저 장하면 한동안 그대로 유 지하고 그 브랜치 에서는 계속 새로운 일을 한다. 그러면 저장 
한 Stash 를 격 용하는 것이 문제가 될 수 있다. 수정한 파일에 Stash 를 적 용하면 충돌이 날 수 있다. 충 

돌이 나면충 돌을해 결해야 한다. 그리고 Stash 한것 은다시 테스 트해야 한다. git stash branch 명령 

을 실 행하면 Stash 할 당시의 커밋을 Checkout 한 후 새로운 브 탠치를 만들고 여기에 격용 한다. 이 모 
든 것이 성 공하면 Stash 를삭제 한다: 



$ git stash branch testchanges 
Switched to a new branch "testchanges" 

# On branch testchanges 

# Changes to be committed: 

# (use "git reset HEAD <f ile>. . . " to unstage) 

# 

# modified ： index . html 

# 

# Changes not staged for commit: 

# (use "git add <f ile>. . . " to update what will be committed) 
# 



153 



6 장 Git 도구 Scott Chacon Pro Git 



# modified: lib/simplegit.rb 
# 

Dropped refs/stash@{0} ( f Odf c4d5dc332d1 cee34a6341 82e1 68c4ef c3359) 




이 명렁은 브 탠치를 새로 만들고 Stash 를 복원 해주는 매우 편리한 도 구다. 



6.4 히스 토리단 장하기 

Git 으로 일하다 보면 어떤 이 유로든 커밋 히스 토리를 수 정해야 할 때가 있다. 결정을 나 중으로 미를 수 
있던 것은 Git 의 장점 이다. Staging Area 가 있어서 커밋할 파일을 고르는 일을 커 밋하는 순 간으로 미 
를 수있고 Stash 명령으 로하던 일을 미룰수 있다. 게다 가이미 커 밋한내 용을수 정할수 있다. 거의모 
든 것을 수정할 수 있다. 커밋 순서도 변경할 수 있고 커밋 메 시지와 커밋한 파일도 변경할 수 있다. 여 
러 개의 커 밋을하 나로합 치거나 반대로 하나의 커밋 을여러 개 로분리 할수도 있다. 아니면 커 밋견체 
를 삭제할 수도 있다. 하 지만， 이 모든 것은 다른 사람과 코드를 공 유하기 견에 해야 한다. 
이 결 에서는 사 람들과 코드를 공 유하기 견에 커밋 히스 토리를 예쁘게 단 장하는 방법에 대해서 설명한 
다. 



6.4.1 마 지막커 밋을수 정하기 

히스 토리를 단 장하는 일 중 에서는 마지막 커밋을 수 정하는 것이 가장 자주 하는 일 이다. 기본 적으로 두 
가지로 나눌 수 있는데 하나는 커밋 메 시지를 수 정하는 것이고 다른 하나는 파일 목록을 수 정하는 것이 
다. 

커밋 메 시지를 수 정하는 방법은 매우 간단 하다: 



$ git commit —amend 



이 명렁은 자동으 로텍스 트편집 기를실 행시켜 서마지 막커밋 메시지 를열어 준다. 여기에 메시 지를수 

정하고 편 집기를 닫으면 편 집기는 수정한 메 시지로 마지막 커밋을 수정 한다. 

커 밋하고 나서 새로 만 들었거 나 다시 수정한 파일을 □ ᅡ지 막 커 밋에 포함할 수 있다. 기본 적으로 방법은 

같다. 파일을 수 정하고 git add 명 령으로 Staging Area 에 넣거나 git rm 명 령으로 파일 삭제 한다. 그 
리고 git commit -amend 명렁 으로커 밋하면 된다. 이 명 령은현 Staging Area 의 내 용을이 용해서 수 
정 한다. 

이때 SHA-1 값이 바뀌기 때문에 과거의 커밋을 변경할 때 주 의해야 한다. rebase 처럼 이미 Push 한 
커밋 은수정 하면안 된다. 

6.4.2 커 밋메시 지를여 러개수 정하기 

최근 커밋이 아니 라예견 커밋 을수정 하려면 다 른도구 가필요 하다. 히 스토리 수정용 도구는 없지만 

rebase 명 령을이 용하여 수 정할수 있다. 현재 작업하 는브탠 치에서 각커 밋을하 나하나 수정하 는것이 

아니라 어느시 점부터 HEAD 까지의 커밋을 한번에 Rebase 한다. 대화형 Rebase 도 구를사 용하면 커 
밋을처 리할때 마다멈 춘다. 그러면 각 커밋의 메 시지를 수정하 거나파 일을추 가하고 변경하 는등의 일 
을 진행할 수 있다. git rebase 명렁에 -i 옵션을 추 가하면 대화형 모드로 Rebase 할 수 있다. 어떤 시점 
부터 HEAD 까지 Rebase 할 것인지 아규 먼트로 님기면 된다. 
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6.4 절 히 스토리 단 캉하기 



마지막 커밋 메시지 세 개를 모두 수정 하거나 그중 몇 개를 수 정하는 시나 리오를 살펴 보자. git rebase 
—i 의 아규 먼트로 편집 하려는 마지막 커밋의 부모를 HEAD-28 나 HEAD-3 로 해서 님 긴다. 마지막 세 개의 커 
밋을수 정하는 것이기 때문에 ~3 이 좀 더 기 억하기 쉽다. 그렇지 만， 실질적 으로가 리키게 되는 것은수 
정 하려는 커밋의 부모인 네 번째 이견 커밋 이다. 

$ git rebase -i HEAD-3 



이 명령은 rebase 하는 것이기 때문에 메 시지의 수정 여부에 관 게없이 head~3..head 범위에 있 는모든 
커밋 을수정 한다. 다시 강 조하지 만이미 중앙 서버에 Push 한커밋 은결대 고치지 말아야 한다. Push 한 
커밋을 Rebase 하면 결국 같은 내용을 두 번 Push 하는 것이기 때문에 다른 개발 자들이 흔란 스러워 한 
다. 

실 행하면 텍스트 편집기 가열리 고그안 에는수 정하려 는커밋 목록이 첨부 된다: 

pick f7f3f6d changed my name a bit 

pick 310154e updated README formatting and added blame 

pick a5f4a0d added cat-file 

# Rebase 710f0f8. .a5f4a0d onto 71 Of Of 8 

# 

# Commands: 

# p, pick = use commit 

# r, reword = use commit, but edit the commit message 

# e, edit = use commit, but stop for amending 

# s, squash = use commit, but meld into previous commit 

# f, fixup = like "squash", but discard this commit 's log message 

# y、, exec = run command (the rest of the line) using shell 
# 

# These lines can be re-ordered; they are executed from top to bottom. 

# 

# If you remove a line here THAT COMMIT WILL BE LOST. 

# 

# However^ if you remove everything, the rebase will be aborted. 

# 

# Note that empty commits are commented out 



이 커밋은 모두 log 명 렁과는 정 반대의 순서로 나열 된다. log 명렁을 실 행하면 아래와 같은 결과를 
수 있다: 

$ git log — pretty=format:"%h %s" HEAD-3. .HEAD 
a5f4a0d added cat-file 

310154e updated README formatting and added blame 
f7f3f6d changed my name a bit 
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위 결과의 역순임 을기억 하자. 대화형 rebase 는스크 립트에 적혀 있는순 서대로 head~3 부터 적 용하기 
시 작하고 위에서 아래로 각각의 커밋을 순 서대로 수정 한다. 순 서대로 적 용하는 것이기 때문에 제일 위 
에 있 는것이 최신이 아니 라가장 오래된 것 이다. 

특정 커 밋에서 실행을 멈추게 하려면 스크립 트를수 정해야 한다. pick 이라는 단어를 edit 로수 정하면 
그커 밋에서 멈 춘다. 가장 오래된 커밋 메시지 를수정 하려면 아래 와같이 편집 한다: 

edit f7f3f6d changed my name a bit 

pick 310154e updated README formatting and added blame 

pick a5f4a0d added cat-file 



저장하 고편집 기를종 료하면 Git 은 목록에 있 는커밋 중에서 가장 오래된 커밋으 로이동 하고， 아래와 
같은 메시지 를보여 주고， 명렁 프 롬프트 를보여 준다: 

$ git rebase — i HEAD〜3 

Stopped at 7482e0d . . . updated the gemspec to hopefully work better 
You can amend the commit now, with 

git commit —amend 

Once you ' re satisfied with your changes, run 



git rebase —continue 




정확히 뭘 해야 하는지 알려 준다. 아래와 같은 명렁을 실행 하고: 



$ git commit —amend 




커밋 메시 지를수 정하고 텍스트 편집기 를종료 한다. 그리 고아래 명령어 를실행 한다: 

$ git rebase —continue 



이렇게 나머지 두 개의 커밋에 격 용하면 끝 이다. 다른 것도 pick 을 ed i t 로 수 정해서 이 작업을 몇 번이 
든 반복할 수 있다. Git 이 멈출 때마다 커밋을 수정할 수 있고 완료할 때까지 계속 할 수 있다. 

6.4.3 커 밋순서 바꾸기 

대화형 Rebase 도구로 커밋 견체를 삭 제하고 순서도 바꿀 수 있다. "added cat-file" 커밋을 삭제하 
고 다른 두 커밋의 순서를 변경 하려면 이 rebase 스크립 트를: 
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6.4 절 히스 토리단 캉하기 



pick f7f3f6d changed my name a bit 

pick 310154e updated README formatting and added blame 

pick a5f4a0d added cat-file 



아 래와같 이수정 한다: 

pick 310154e updated README formatting and added blame 
pick f7f3f6d changed my name a bit 



수정한 내용을 저장하 고편집 기를종 료하면 Git 은 브랜치 를이커 밋들의 부모로 이동시 키고서 310154e 와 

f7f3f6d 를순 서대 로격용 한다. 그러면 커밋 순서가 변 경됐고 "added cat-file" 커밋이 제거된 것을확 
인할수 있다. 

6.4.4 커밋 합치기 

대화형 Rebase 명렁을 이 용하여 여러 개의 커밋을 꾹꾹 늘러서 하나의 커 밋으로 만들어 버릴 수 있다. 
Rebase 스크 립트에 자 동으로 포함된 도 움말에 설명돼 있다: 

# 

# Commands: 

# p, pick = use commit 

# r, reword = use commit, but edit the commit message 

# e, edit = use commit, but stop for amending 

# s, squash = use commit, but meld into previous commit 

# f, fixup = like "squash", but discard this commit 's log message 

# y、, exec = run command (the rest of the line) using shell 
# 

# These lines can be re-ordered; they are executed from top to bottom. 

# 

# If you remove a line here THAT COMMIT WILL BE LOST. 

# 

# However^ if you remove everything, the rebase will be aborted. 
# 

# Note that empty commits are commented out 




"pick" 이나 "edit" 말고 "squash" 를 입 력하면 Git 은 해당 커밋과 바로 이전 커밋을 합칠 것이고 커밋 
메 시지도 Merge 한다. 그래서 3 개의 커밋을 모두 합 치려면 스크 립트를 아래와 같이 수정 한다: 

pick f7f3f6d changed my name a bit 

squash 310154e updated README formatting and added blame 
squash a5f4a0d added cat-file 
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저 장하고 나서 편 집기를 종 료하면 Git 은 3 개의 커밋 메 시지를 Merge 할 수 있도록 에 디터를 바로 실행 
해 준다: 

# This is a combination of 3 commits. 

# The first commit 's message is: 
changed my name a bit 

# This is the 2nd commit message: 
updated README formatting and added blame 

# This is the 3rd commit message: 
added cat-file 

이 메시 지를저 장하면 3 개의 커밋이 모두 합처진 하나의 커밋만 남 는다. 
6.4.5 커밋분 리하기 

커밋을 분리 한다는 것은 기존 커밋을 Reset 하고 (흑은 되돌려 놓고) Stage 를여러 개로 분 리하고 나 
서 그것을 원하는 횟 수만큼 다시 커 밋하는 것 이다. 예로 들었던 커밋세 개 중에서 가운데 것을 분리 
해 보자. 이 커밋은 "updated README formatting and added blame" 라는커 밋인데 "updated 
README formatting" 과 "added blame" 으로 분리해 보자. rebase -i 스크립 트에서 해당 커밋을 
"edit" 로 변경 한다: 

pick f7f3f6d changed my name a bit 

edit 310154e updated README formatting and added blame 

pick a5f4a0d added cat-file 



위와 같이 수 정하고 나서 저 장하고 편 집기를 종 료하면 Git 은 제일 오래된 커밋의 부모로 이동 하고서 

f7f3f6d 과 310154e 을처 리하고 콘솔프 롬프트 를보여 준다. 여 기서커 밋을해 제하는 git reset HEAffl 라 

는 명 령으로 커밋을 해제 한다. 그러면 수 정했던 파일은 Unstaged 상태가 된다. 그 다음에 파 일들을 

Stage 한 후 커 밋하는 일을 원하는 만큼 반 복하고 나서 git rebase -continue 라는 명렁을 실 행하면 남 

은 Rebase 작 업이끝 난다: 

$ git reset HEAD A 
$ git add README 

$ git commit -m 'updated README formatting' 
$ git add lib/simplegit.rb 
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6.4 절 히스 토리단 캉하기 



$ git commit -m 'added blame 
$ git rebase —continue 




나머지 a5Ha0d 커 밋도처 리되면 히스 토리는 아래와 같다: 



$ git log —4 — pretty=format: "%h %s 

1cO02dd added cat-file 

9b291 57 added blame 

35cfb2b updated README formatting 

f3cc40e changed my name a bit 



다시 강 조하지 만， 목록에 있는 모든 커밋의 SHA-1 값은 변경 된다. 그래서 이미 서버에 Push 한 커밋 

을수정 하면안 된다. 

6.4.6 filter-branch 는포 크레인 

수정해 야하는 커밋이 너무 많아서 rebase 스크 립트로 수 정하기 어려울 것 같으면 다른 방 법을사 
용하는 것이 좋다. 모든 커밋의 이메일 주소를 변 경하거 나어떤 파일을 삭 제하는 경우를 살펴 보자. 
filter-branch 라는명 령으로 수 정할수 있는데 rebase 가삽 이라면 이 명 렁은포 크레인 이라고 할수있 

다. filter-branch 도 역시 수정 하려는 커밋 이이미 공 개돼서 다 른사람 과함께 공유 하는중 이라면 사용 
하지 말아야 한다. 하 지만, 잘쓰면 꾀 I 유용 하다. filter-branch 가어떤 경우에 유 용할지 예를 들어서 설 
명 한다. 

모 든커밋 에서파 일을제 거하기 

갑 자기누 군가생 각없이 g it add . 같은명 령어를 실행해 버려서 공룡동 덩어리 가커밋 됐거나 실수로 

암호가 포함된 파일을 커 밋해서 이런 파 일들을 다시 삭 제해야 하는 상황을 살펴 보자. 이런 상황은 생 

각보다 차주 발생 한다. filter-branch 는 히 스토리 견체 에서 필요한 것만 골 라내는 데 사 용하는 도 구다. 
filter— branch 의 —tree— filter 라는옵 션을사 용하면 히스토 리에서 passwords.txt 라 는파일 을아예 
제 거할수 있다: 

$ git filter-branch ―— tree-filter 'rm — f passwords.txt' HEAD 
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21) 
Ref 'refs/heads/master' was rewritten 



-tree-filter 옵션은 프로 젝트를 Checkout 한 후에 각 커밋에 명시한 명 렁어를 실행 시키고 그 결과를 
다시 커밋 한다. 이 예 제에서 는각스 냅샷에 passwords.txt 라는 파일이 있으면 그파일 을삭제 한다. 실 

수 로편집 기의백 업파일 을커밋 했으면 git filter-branch -tree-filter "find * -type f -name '*-' 
-delete" HEAD 라고 실 행해서 삭제할 수 있다. 

이명령 은모든 파일과 커밋을 정 리하고 브탠치 포 인터를 다시 복원해 준다. 테스팅 브탠 치에서 사용할 
명령을 점 검하고 나서 master 브랜치 를정리 한다. 그리고 filter-branch 명렁에 -all 옵션을 추가하 
면모든 브탠치 에격용 된다. 
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하위 디텍 토리를 루트 디렉 토리로 만들기 

다른 VCS 에서 코드를 임포 트하면 그 VCS 만을 위한 디텍 토리가 있을 수 있다. SVN 에서 코드를 임포 
트하면 trunk, tags, branch 디 텍토리 가포함 된다. 모든 커밋에 대해 trunk 디텍 토리를 프로젝 트루트 

디롁 토리로 만들 때에도 filter-branch 명령이 유용 하다: 

$ git filter-branch ―— subdirectory-filter trunk HEAD 
Rewrite 856f 0bf 61 e41 a27326cdae8f 09f e708d679f 596f (12/12) 
Ref 'refs/heads/master' was rewritten 



이제 trunk 디 텍토리 를루트 디롁 토리로 만들 었다. Git 은 입력한 디롁 토리와 관련이 없는 커밋 을자동 
으 로삭제 한다. 

모든커 밋의이 메일주 소를수 정하기 

프로젝 트를오 픈소스 로공개 할때에 도회사 이메일 주소로 커밋된 것 을개인 이메일 주소로 변 경해야 
한다. 아니 면아예 git config 로이름 과이메 일주소 를설정 하는것 을잊었 을수도 있다. 어쨌든 filter- 
branch 명령의 -comit-filter 옵 션을사 용하여 각 커밋에 등록된 이메일 주 소를수 정할수 있다. 이메 
일 주소를 변경할 때는 조 심해야 한다. 



$ git filter-branch ―— commit— filter ' 

if [ "$GIT_AUTHOR_EMAIL" = "schaconSlocalhost" 
then 

GIT_AUTHOR_NAME=" Scott Chacon"; 
GIT_AUTHOR_EMAIL="schacon@example.com"; 
git commit— tree "$@"; 

else 

git commit— tree "$@"; 

fi' HEAD 



이메일 주소를 새주소 로변경 했다. 모든 커밋은 부모의 SHA-1 값 을가지 고있기 때문에 조건에 만족 
하는 커밋의 SHA-1 값 만바뀌 는것이 아니 라모든 커밋의 SHA-1 값이 바 뀐다. 

6.5 Git 으로버 그찾기 

Git 은 굉장히 유 연해서 어떤프 로젝트 에나사 용할수 있다. 게다가 문제를 일으킨 범인 이나버 그도쉽 
게찾을 수있도 록도와 준다. 

6.5.1 파 일어노 테이션 

버그를 찾을 때 먼저 그 코드 가왜, 언제 추가 했는지 알고 싶을 것 이다. 이때는 파일 어노테 이션을 활용 
한다. 한 줄한줄 마지 막으로 커밋한 사람이 누구 인지, 언제 마지 막으로 커밋 했는지 볼 수 있다. 어떤 메 

소드에 버그가 있으면 git blame 명 령으로 그 메 소드의 각 줄을 누가 언제 마지 막으로 고 쳤는지 찾아널 
수 있다: 
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6.5 절 Git 으로버 그찾기 



$ git blame — L 12,22 simplegit.rb 



A 4832fe2 


(Scott Chacon 


2008-03-15 


10： 


:31 


:28 


-0700 


12) 


def show (tree = 'master' ) 


A 4832fe2 


(Scott Chacon 


2008-03-15 


10： 


:31 


:28 


-0700 


13) 


command( "git show #{tree}") 


A 4832fe2 


(Scott Chacon 


2008-03-15 


10： 


:31 


：28 


-0700 


14) 


end 


A 4832fe2 


(Scott Chacon 


2008-03-15 


10： 


:31 


:28 


-0700 


15) 




9f6560e4 


(Scott Chacon 


2008-03-17 


21： 


：52 


：20 


-0700 


16) 


def log (tree = 'master' ) 


79eaf55d 


(Scott Chacon 


2008-04-06 


10： 


：15 


：08 


-0700 


17) 


command( "git log #{tree}") 


9f6560e4 


(Scott Chacon 


2008-03-17 


21： 


：52 


：20 


-0700 


18) 


end 


9f6560e4 


(Scott Chacon 


2008-03-17 


21： 


：52 


：20 


-0700 


19) 




42cf2861 


(Magnus Chacon 2008-04-13 


10： 


：45 


：01 


-0700 


20) 


def blame(path) 


42cf2861 


(Magnus Chacon 


2008-04-13 


10： 


■ 


：01 


-0700 


21) 


command( "git blame #{path}") 


42c f 2861 


(Magnus Chacon 2008-04-13 


10： 


：45 


：01 


-0700 


22) 


end 



첫항 목은그 줄을마 지막에 수정한 커밋의 SHA—1 값 이다. 그 다음두 항목은 누가， 언 제그즐 을커밋 
했는지 보여 준다. 그래서 누가， 언제 커밋 했는지 쉽게 찾을 수 있다. 그 뒤에 파일의 즐 번호와 내용을 보 

여 준다. 그리고 N4832fe2 커밋이 궁금할 텐데 이 표시 가붙어 있으면 해 당즐이 처음 커밋한 것을 의미한 
다. 그러 니까해 당즐은 4832fe2 에서 커밋된 후 변경된 적이 없다. 지 금까지 커 밋을수 정하는 것을 배우 
면서 I 을 적어도 세 곳에서 사용 한다고 배웠기 때문에 약간 헷갈릴 수 있으니 혼 동하지 말자. 
Git 은파일 이름 을변경 한이력 을별도 로기록 해두지 않 는다. 하 지만， 원래 이 정보들 은각스 냅샷에 
저 장되고 이 정보를 이 용하여 변경 이력을 만들어 낼 수 있다. 그 러니까 파일에 생긴 변화는 무엇이 
든지 알아낼 수 있다. Git 은파일 어 노테이 션을분 석하여 코 드들이 원래 어떤 파 일에서 커밋된 것인 
지 찾아 준다. 예를 들어 보자. GITServerHandler.m 을여러 개의 파일로 리 팩토링 했는데 그중한 파일이 
GITPackUpload.ni 이라는 파일 이라고 하자. -C 옵 션으로 GITPackUpload.m 파일을 추격 해보면 각 코드가 
원래 어떤 파일로 커밋된 것인지 알 수 있다: 



$ git blame -C -L 141,153 
f344f58d GITServerHandler. 
f344f58d GITServerHandler. 
f344f58d GITServerHandler. 
70befddd GITServerHandler. 
ad11ac80 GITPackUpload.m 
ad11ac80 GITPackUpload.m 
ad11ac80 GITPackUpload.m 
ad11ac80 GITPackUpload.m 
ad11ac80 GITPackUpload.m 
ad11ac80 GITPackUpload.m 
56ef2caf GITServerHandler. 
56ef2caf GITServerHandler. 
56ef2caf GITServerHandler. 



GITPackUpload.m 
m (Scott 2009-01-04 
m (Scott 2009-01-04 
m (Scott 2009-01-04 
m (Scott 2009-03-22 
(Scott 2009-03-24 
(Scott 2009-03-24 
(Scott 2009-03-24 
(Scott 2009-03-24 
(Scott 2009-03-24 
(Scott 2009-03-24 
m (Scott 2009-01-05 
m (Scott 2009-01-05 
m (Scott 2009-01-05 



141) 

142) - (void) gatherObj ectShasFromC 

143) { 

//NSLog(@"GATHER COMMI 



144) 
145) 
146) 
147) 
148) 
149) 
150) 
151) 
152) 
153) 



NSString *parentSha; 
GITCommit ^commit = [g 

//NSLog(@"GATHER COMMI 

if (commit) { 

[refDict setOb 



언제나 코드가 커밋될 당시의 파일 이름을 알 수 있기 때문에 코드를 어떻게 리팩토 링해도 추적할 수 있 
다. 그 리고어 떤파일 에적용 해봐도 각즐을 커밋할 당시의 파 일이름 을알수 있다. 버그 를찾을 때정말 
유용 하다. 
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6.5.2 이 진람색 

파일 어노 테이션 은특정 이슈와 관련된 커밋 을찾는 데에도 좋다. 문 제가생 겼을때 의심 스러운 커밋이 

수십， 수백 개에 이르면 도대체 어디 서부터 시작해 야할지 모를수 있다. 이때는 git bisect 명령이 유용 
하다. bisect 명렁은 커 밋히스 토리를 이진 람색 방 법으로 좁혀 주기 때문에 이슈와 관런된 커밋을 최대 
한 빠르게 찾아낼 수 있도록 도와 준다. 

코드를 운용 환경에 배 포하고 난 후에 개발할 때 발 견하지 못한 버그가 있다고 보고받 았다. 그런데 왜 
그런 현상이 발생 하는지 아직 이 해하지 못하는 상황을 가정해 보자. 해당 이슈를 다시 만들고 작 업하기 
시작 했는데 뭐가 잘못 됐는지 알아널 수 없다. 이럴때 bisect 를 사 용하여 코드를 뒤겨 보는 게 좋다. 먼 

겨 git bisect start 명 령으로 이진탑 색을시 작하고 git bisect bad 를실 행하여 현재커 밋에문 계가있 
다고표 시를남 기고나 서문제 가없는 마지막 커밋을 git bisect good [good.commit] 명 렁으로 표시한 
다. 

$ git bisect start 

$ git bisect bad 

$ git bisect good v1 .0 

Bisecting: 6 revisions left to test after this 
[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo 



이 예 제에서 마지막 으로괜 찮았던 커밋 (V1.0) 과현재 문 제가있 는커밋 사이에 있 는커밋 은전부 12 개 
이고 Git 은그 중간에 있는 커밋을 Checkout 해 준다. 여 기에서 해 당이슈 가구현 됐는지 테스트 해보고 
만약 이슈가 있으면 그중간 커밋이 견으로 범위를 좁히고 이슈가 없으면 그중간 커밋이 후로범 위를좁 

힌다. 이슈 를발견 하지못 했으면 git bisect good 으 로이슈 가아직 없 음을알 리고계 속진행 한다: 

$ git bisect good 

Bisecting: 3 revisions left to test after this 

[ b047b02ea8331 0a70f d603dc8cd7a6cd1 3d1 5c04] secure this thing 



현재 문제가 있는 커밋과 지금 테 스트한 커밋사 이에서 중간에 있는 커밋이 Checkout 됐다. 다시 테스 

트 해보고 이슈가 있으면 git bisect bad 로이 슈가있 다고알 린다: 

$ git bisect bad 

Bisecting: 1 revisions left to test after this 

[ f 71 ce38690acf 49c1 f 3c9bea38e09d82a5ce6014] drop exceptions table 



이제 이슈를 처음구 현한커 밋을찾 았다. 이 SHA-1 값을 포함한 이커밋 의정보 를확인 하고수 정된파 
일이 무 엇인지 확인 한다. 이 문제가 발생한 시점에 도대체 무슨 일이 있 었는지 아래와 같이 살펴 본다: 



$ git bisect good 




b047b02ea8331 0a70fd603dc8cd7a6cd1 3d1 5c©4 i 


s first bad commit 
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6.6 절 서브 모- 



commit b047b02ea8331 0a70fd603dc8cd7a6cd1 3d1 5cG4 
Author: P3 Hyett 〈pjhyett@example.com〉 
Date: Tue 3an 27 14:48:32 2009 -0800 

secure this thing 

： 040000 040000 40ee3e7821 b895e52d 695092db9bdc4c61 d1 730 
f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config 



이제 찾았 으니까 git bisect reset 명렁 을실행 시켜서 이진 람 색을시 작하기 전으로 HEAD 를돌려 
는다: 



$ git bisect reset 



수백 개의 커밋들 중에서 버그가 만 들어진 커밋을 찾는 데 몇 분밖에 걸리지 않 는다. 프로 젝트가 정상 

격으로 수 행되면 0 을 반 환하고 문제가 있 을경우 1 을 반 환하는 스크 립트를 만들면 이 git bisect 과정 
을 완견히 자동화 할 수 있다. 먼겨 bisect start 명 렁으로 bisect 를 사용할 범위를 알려 준다. 위에서 한 
것처럼 문제가 있다고 아는 커밋과 문제가 없다고 아는 커밋을 넘기면 된다: 

$ git bisect start HEAD v1 .0 
$ git bisect run test-error. sh 



문제가 생긴 첫 커밋을 찾을 때까지 Checkout 할 때마다 test-error. sh 를 실행 한다. make 든지 make 
tests 든지 어쨌든 이슈를 찾는 테 스트를 실 행하여 찾 는다. 



6.6 서 브모들 

프로 젝트를 수 행하다 보면 다른 프로 젝트를 사 용해야 하는 경우가 종종 있다. 보통 사용할 프로 젝트들 
은독립 적으로 개발된 라이브 러리들 이다. 이런상 황에서 자주생 기는이 슈는， 두 프로젝 트를서 로별개 
로 다루 면서도 그 중 하나를 다른 하나 안에서 사용할 수 있어야 한다는 것 이다. 

Atom 피드를 제 공하는 웹사 이트를 만 든다고 가장 하자. Atom 피드를 생 성하는 코드는 직집 작 성하지 
않고 라이브 러리를 가져다 쓰기로 했다. 그러면 CPAN 이나 Ruby gem 같은 라이 브러리 관리 도구를 
사용 하거나 해당 소스 코드를 프로 젝트로 복 사해야 한다. 사실 라이브 러리를 수 정하는 것은 어 렵다. 하 
지만 수정한 라이브 러리를 모든 사 용자가 이용할 수 있도록 배 포하는 것은 더 어 렵다. 그래서 프 로젝트 
에 라이 브러리 코드 를포함 시켜서 수 정하는 방법 도사용 한다. 이렇게 라이 브러리 코드 를포함 시키면 
원래 라이 브러리 프로 젝트의 코드와 Merge 하기 어렵게 된다. 

Git 의 서브 모듈은 이런 문제를 해결해 준다. 서브 모듈은 Git 겨장소 안에 다른 Git 저 장소를 들 수 있게 
해 준다. 이렇게 해도 두 Git 저장소 모두 여전히 독립 격으로 관리 된다. 
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6.6.1 서브 모들시 작하기 

한번 Ruby 웹서버 게이 트웨이 인터페 이스인 Rack 라이 브러리 를프로 젝트에 추가해 보자. 추 가하고 
나서도 앞으로 여견히 해당 저장 소에서 관리할 수 있기 때문에 마음 놓고 코드를 수정할 수 있다. 먼저 

git submodule add 명 렁으로 프로젝 트를서 브모듈 로추가 한다: 



$ git submodule add git ： //github . com/ chneukirchen/rack . git rack 

Initialized empty Git repository in /opt/subtest/rack/ . git/ 

remote: Counting objects: 3181, done. 

remote: Compressing objects: 100% (1534/1534), done. 

remote: Total 3181 (delta 1951), reused 2623 (delta 1603) 

Receiving objects: 100% (3181/3181), 675.42 KiB | 422 KiB/s, done. 

Resolving deltas: 100% (1951/1951), done. 



이제 프 로젝트 디텍 토리를 보면 rack 이라는 디롁 토리가 생겼을 것 이다. 그 디롁 토리가 Rack 프 로젝트 
이다. rack 디 롁토리 안에서 수 정하고 Push 할 권한이 있는 저 장소를 하나 추 가하고 나서 그 저 장소에 

Push 한다. 물론 원래 프 로젝트 저장소 에서도 Fetch 하고 Merge 할 수 있다. 서브 모듈을 추가한 직후 

바로 git status 라는 명렁을 실 행하면 아래와 같이 두 파일이 생긴 것을 알 수 있다: 



$ git status 

# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <f ile>. . . " to unstage) 

# 

# new file: .gitmodules 

# new file: rack 
# 




.gitmodules 파일 을살펴 보자. 이 것 은로컬 디롁토 리와프 로젝트 URL 의 매핑 정 보가저 장된설 정파일 
이다: 



$ cat .gitmodules 
[submodule "rack" ] 
path = rack 

url = git: //github. com/chneukirchen/rack. git 



서브모 들개수 만큼이 항목이 생 긴다. 이 파일도 .gitignore 파 일처럼 버전 관리 된다. 다른파 일처럼 
Push 하고풀 한다. 이프로 젝트를 Clone 하는 사람은 .gitmodules 파일을 보고어 떤서브 모들프 로젝트 
가있는 지알수 있다. 

.gitmodules 은 살펴봤 고이제 rack 항목에 대 해살펴 보자. git diff 명령 을실행 시키면 흥미로 운점을 
발 견할수 있다: 
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$ git diff ―— cached rack 
diff —git a/rack b/rack 
new file mode 160000 
index 0000000. .08d709f 
— /dev/null 
+++ b/rack 
@@ -0,0 +1 @@ 

+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433 



Git 은 rack 디롁 토리를 서브 모듈로 취 급하기 때문에 파 일들을 직접 추 적하지 않고 커밋 하나만 저장한 
다. rack 디롁토 리에서 수정을 하고커 밋하면 다 른사람 이같은 환경을 만들수 있도록 HEAD 가 가리키 
는 커밋이 슈 퍼프로 젝트에 저장 된다. 

master 처럼 브랜치 이름같 은레퍼 런스가 저장되 는것이 아니라 커밋의 SHA-1 값이 저장 된다ᅳ 
슈퍼 프로젝 트도커 밋해야 된다: 



$ git commit -m 'first commit with submodule rack 
[master 0550271 ] first commit with submodule rack 

2 files changed, 4 insertions(+) , 0 deletions(-) 

create mode 1 00644 .gitmodules 



create mode 160000 rack 




rack 디롁 토리의 모드는 160000 이다. 160000 모드는 일반격 인파일 이나디 렉토리 가아니 라는의 
미다. 

하위 프로 잭트의 마지막 커밋이 바뀔 때 마다슈 퍼프로 젝트에 저장된 커밋도 바꿔 준다. rack 디 텍토리 
를 별도의 프로 젝트로 취 급하기 때문에 모든 Git 명렁은 독립 적으로 동작 한다: 



$ git log -1 

commit 0550271 328a0038865aad6331 e620cd7238601 bb 
Author: Scott Chacon 〈schacon@gmail.com〉 
Date: Thu Apr 9 09:03:56 2009 -0700 

first commit with submodule rack 
$ cd rack/ 
$ git log -1 

commit 08d709f78b8c5b0fbeb7821 e37fa53e69afcf433 
Author: Christian Neukirchen 〈chneukirchen@gmail.com〉 
Date: Wed Mar 25 14:49:04 2009 +0100 



Document version change 
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6.6.2 서브 모들이 있는 프 로젝트 Clone 하기 

서브 모듈을 사용하 는프로 젝트를 Clone 하면 해당서 브모듈 디롁 토리는 빈 디롁터 리다: 

$ git clone git://github.coni/schacon/myproject .git 

Initialized empty Git repository in /opt/myproject/.git/ 

remote: Counting objects: 6, done. 

remote: Compressing objects: 100% (4/4) , done. 

remote: Total 6 (delta 0) f reused 0 (delta 0) 

Receiving objects: 100% (6/6), done. 

$ cd myproject 

$ Is -1 

total 8 

-rw-r-r— 1 schacon admin 3 Apr 9 09： 11 README 
drwxr-xr-x 2 schacon admin 68 Apr 9 09:11 rack 
$ Is rack/ 
$ 



분명히 rack 디텍 토리가 있지만 비워져 있다. 먼저 git submodule init 명 렁으로 서브모 들을초 기화하 
고 git submodule update 명렁 으로서 버에서 데이터 를가겨 온다. 데이터 를전부 가겨오 면슈퍼 프로젝 

트에 저장된 커 밋으로 Checkout 된다: 

$ git submodule init 

Submodule 'rack' (git ://github.com/chneukirchen/rack.git) registered for path 'rack 1 
$ git submodule update 

Initialized empty Git repository in /opt/myproject/rack/.git/ 

remote: Counting objects: 3181 , done. 

remote: Compressing objects: 100% (1534/1534), done. 

remote: Total 3181 (delta 1951), reused 2623 (delta 1603) 

Receiving objects: 100% (3181/3181), 675.42 KiB | 173 KiB/s, done. 

Resolving deltas: 100% (1951/1951), done. 

Submodule path 'rack' ： checked out 1 08d709f 78b8c5b0f beb7821e37f a53e69af cf 433 1 




rack 디롁 토리는 이제 복원 했다. 그리고 누군가 rack 을 수 정하면 그 코드를 가겨다 Merge 한다: 



$ git merge origin/master 
Updating 0550271 . .85a3eee 
Fast forward 
rack ！ 2 +— 

1 files changed, 1 insertions(+) f 1 deletions (ᅳ) 
[ master* ]$ git status 
# On branch master 
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# Changes not staged for commit: 

# (use "git add <f ile>. . . " to update what will be committed) 

# (use "git check ᄋ니 t ―— <f ile>. . . " to discard changes in working directory) 
# 

# modified: rack 
# 



Merge 해 서서브 모듈의 HEAD 값이 변경 됐다. 슈퍼 프로젝 트가아 는커밋 과서브 모듈의 HEAD 가달 
라서 아직 워킹 디텍토 리의상 태는깨 끗한상 태가아 니다: 

$ git diff 

diff —git a/rack b/rack 
index 6c5e70b. .08d709f 160000 
— a/rack 
+++ b/rack 
@@ -1 +1 @@ 



-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf 58e0 
+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433 




이럴때 git submodule update 명령을 실행해 서해결 한다: 



$ git submodule update 

remote: Counting objects: 5, done. 

remote: Compressing objects: 100% (3/3), done. 

remote: Total 3 (delta 1 ) f reused 2 (delta 0) 

Unpacking objects: 100% (3/3), done. 

From git@github.com： schacon/rack 

08d709f . .6c5e70b master -> origin/master 
Submodule path 'rack' ： checked out '6c5e70b984a60b3cecd395edd5b48a7575bf 58e0 



서브 모들프 로젝트 를풀할 때마다 git submodule update 명 렁을실 행해야 한다. 뭔가속 는것같 지만잘 
된다. 

개발 차들이 흔히 저 지르는 실수로 서브 모듈의 코드를 수 정하고 나서 서버에 Push 하지 않는 경우가 있 
다. 슈 퍼프로 젝트는 Push 했지만 프로 젝트가 아는 커밋은 아직 Push 하지 않고 개발자 PC 에만 있다. 

만약 다른개 발자가 git submodule update 를 실행하 면슈퍼 프로젝 트에저 장된커 밋을서 브모들 프로젝 
트에서 찾을 수 없어서 에러가 발생 한다: 

$ git submodule update 

fatal: reference isn ' t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 

Unable to checkout l 6c5e70b984a60b3cecd395edd5ba7575bf58e0' in submodule path 'rack' 
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누가 마지 막으로 서브 모듈을 수정 했는지 확인 하고: 

$ git log -1 rack 

commit 85a3eee996800fcfa91 e21 1 9372dd41 72bf76678 
Author: Scott Chacon 〈schacon@gmail.com〉 
Date: Thu Apr 9 09:19:14 2009 -0700 

added a submodule reference I will never make public, hahahahaha! 



그 개발 자에게 이메일 을보내 거나견 호ᅡ를 건다. 

6.6.3 슈퍼프 로젝트 

프 로젝트 규모가 크면 CVS 나 Subversion 에서는 모듈 프로 젝트를 간단히 하위 디랙 토리로 만들 었다. 
가끔 Git 에서도 이런 Workflow 을 사용 하려는 개발 자들이 있다. 

Git 에서는 각 하위 디텍 토리를 별도의 Git 저 장소로 만 들어야 한다. 그리고 그 저 장소를 포 함하는 상위 
저 장소를 만 든다. 슈 퍼프로 젝트의 태그와 브 탠치를 이 용해서 각 프로 젝트의 관게를 구체 적으로 정의할 
수있다 는것은 Git 만 의장점 이다. 

6.6.4 서 브모들 시용할 때 주의할 점들 

전체 적으로 서브 모들은 어렵지 않게 사용할 수 있 지만, 서브 모듈의 코드를 수 정하는 경 우에는 주의가 

필요 하다. git submodule update 명 령을실 행시키 면특정 브탠치 가아니 라슈퍼 프로젝 트에저 장된커 
밋을 Checkout 해버 린다. 그러면 detached HEAD 라고 부르는 상태가 된다. detached HEAD 는 HE AD 가 
브 탠치나 태그 같은 간집 레퍼 런스를 가 리키지 않고 커밋을 가 리키는 것을 말 한다. 데 이터를 잃어 버릴 
수도 있기 때문에 일반 격으로 detached HEAD 상태는 피해야 한다. 

submodule update 를 실 행하고 나서 별도의 작업용 브 탠치를 만들지 않고 서 브모듈 코드를 수 정하고 커 
밋 한다. 그리고 나중에 커밋한 것을 잊 은채로 슈퍼 프로젝 트에서 다시 git submodule update 를 실행시 
키면 Git 은 아무 말 없이 Checkout 해 버 린다. 엄밀히 말해서 커밋을 없어진 것은 아 니지만 브 탠치에 
속하지 않는 커밋을 찾아 내기란 정말어 렵다. 

git checkout -b work 같은 명 령으로 작업할 때마다 work 브 탠치를 만들면 이 문제를 피할 수 있다. 실 
수로 submodule update 명령을 실행해 버려서 하던 일을 놓처 버려도 포 인터가 있어서 언 제든지 되찾을 
수 있다. 

그리고 서브 모들이 있는 슈 퍼프로 젝트의 브 랜치를 오갈 때는 약간의 추가 작업이 필요 하다. 브 랜치를 
만들고 서브 모듈을 추가 한다. 그 다음에 서브 모들이 없는 브 랜치로 돌아 간다. 그렇지 만, 이미 추가한 

서 브모들 디텍 토리가 untracked 상태로 보 인다: 

$ git checkout — b rack 
Switched to a new branch "rack" 

$ git submodule add gitigithub . com ： schacon/rack .git rack 
Initialized empty Git repository in /opt/myproj /rack/ .git/ 

Receiving objects: 100% (3184/3184), 677.42 KiB ！ 34 KiB/s, done. 
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Resolving deltas: 100% (1952/1952), done. 
$ git commit —am 1 added rack submodule' 
[rack cc49a69] added rack submodule 

2 files changed, 4 insertions(+) f 0 deletions(-) 

create mode 1 00644 .gitmodules 

create mode 160000 rack 
$ git checkout master 
Switched to branch "master" 
$ git status 

# On branch master 

# Un tracked files: 

# (use "git add <f ile>. . . " to include in what will be committed) 
# 

# rack/ 



서 브모듈 디텍 토리를 다른 곳에 옮겨 두거나 삭 제해야 한다. 삭제할 경우는 원래 브 랜치로 돌 아왔을 때 

서브 모들을 다시 Clone 해야 하고， 이 경우 아직 Push 하지 않았던 변경사 항이나 브 랜치를 잃 을수있 
다, 

rack 이라는 디롁토 리가있 고이것 을서브 모듈로 바꾸려 고한다 고가정 하자. 먼저 rack 디롁토 리를삭 

제하고 submodule add 를 실 행하면 Git 은 아래와 같은 에러를 뱉 는다: 



$ rm -Rf rack/ 

$ git submodule add git@github.com： schacon/rack. git rack 
'rack' already exists in the index 




rack 디롁 토리를 Staging Area 에서 제 거하면 서브 모들을 추가할 수 있다. 



$ git rm — r rack 

$ git submodule add git@github.com： schacon/rack. git rack 

Initialized empty Git repository in /opt/testsub/rack/.git/ 

remote: Counting objects: 3184, done. 

remote: Compressing objects: 100% (1465/1465), done. 

remote: Total 3184 (delta 1952), reused 2770 (delta 1675) 

Receiving objects: 100% (3184/3184), 677.42 KiB | 88 KiB/s, done. 

Resolving deltas: 100% (1952/1952), done. 



한 브탠치 에서는 해결 했다. 아직 해당 디롁 토리를 서브 모듈로 만들지 않은 브 탠치를 Checkout 하려고 
하 면아래 와같은 에러가 난다: 

$ git checkout master 

error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge . 
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다른 브 탠치로 바꾸기 전에 rack 서 브모듈 디롁 토리를 다른 곳으로 옮겨 둔다: 



$ mv rack /tmp/ 
$ git checkout master 
Switched to branch "master 1 
$ Is 

README rack 



그리고 나서 다시 서브 모들이 있는 브 랜치로 돌 아가면 rack 디랙 토리는 텅 비어 있다. git submodule 
update 명 렁으로 다시 Clone 하거나 /tmp/rack/ 에 복 사해둔 파일을 다시 복사 한다. 



6.7 Subtree Merge 

서브 모들시 스렘이 무 엇이고 어디에 쓰는지 배 웠다. 그런데 같은문 제를해 결하는 방법이 또하나 있다. 

Git 은 Merge 하는 시점에 무엇을 Merge 할지， 어떤 견 락을사 용할지 결정해 야한다 ■ Git 은 브탠치 두 
개를 Merge 할 때에는 Recursive 전락을 사 용하고 세 개 이상의 브 랜치를 Merge 할 때에는 Octopus 
견락 을사용 한다. 이 전락은 자동으 로선택 된다. Merge 할브 탠치가 두개면 Recursive 견락이 선택된 
다. Recursive 전락은 Merge 하려는 두 커밋과 공통 조상 커 밋을이 용하는 three-way merge 를 사용하 
기 때문에 단 두 개의 브탠 치에만 적용할 수 있다. Octopus 건락은 브 탠치가 여러 개라도 Merge 할 수 
있지만 비교격 충돌이 쉽게 일어 난다. 

다른 전락도 있는데 그중 하나가 Subtree Merge 다. 이 Merge 는 하위 프 로젝트 문제를 해 결하는 데 
에 도사용 한다. 우 ᅵ에서 사 용했던 Rack 예제를 적용해 보자. 

Subtree Merge 는 마치 하위 프로 젝트가 아예 합처진 것처럼 보일 정도로 한 프로 젝트를 다른 프로젝 

트의 하위 디텍 토리에 연결해 준다. 정 말놀라 운기능 이다. 

Rack 프로 젝트를 리모트 저 장소로 추가 시키고 브 탠치를 Checkout 한다: 



$ git remote add rack_remote git@github.ccim:schacc)n/rack.git 

$ git fetch rack_remote 

warning: no common commits 

remote: Counting objects: 3184, done. 

remote: Compressing objects: 100% (1465/1465), done. 

remote: Total 3184 (delta 1952), reused 2770 (delta 1675) 

Receiving objects: 100% (3184/3184), 677.42 KiB | 4 KiB/s, done. 

Resolving deltas: 100% (1952/1952), done. 

From git@github.com： schacon/rack 

* [new branch] build -> rack— remote/build 

* [new branch] master -> rack— remote/master 

* [new branch] rack-0.4 -> rack— remote/rack— 0.4 

* [new branch] rack— 0.9 -> rack— remote/rack— 0.9 
$ git checkout — b rack— branch rack_remote/master 

Branch rack— branch set up to track remote branch ref s/remotes/rack_remote/ master . 
Switched to a new branch "rack— branch" 
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Checkout 한 rack—branch 의 루트 디렉 토리와 origin 프로 젝트의 master 브 랜치의 루트 디롁 토리는 다 
르다. 브 탠치를 바 꿔가며 어떻게 다른지 확인 한다: 



$ Is 

AUTHORS KNOWN-ISSUES 
COPYING README 
$ git checkout master 
Switched to branch "master" 
$ Is 
README 



Rakefile 
bin 



contrib 
example 



lib 

test 



여 기에서 Rack 프로 젝트를 master 브 탠치의 하위 디롁 토리에 넣 으려면 git read-tree 명 렁어를 사용한 

다. 9 장에서 read-read 류의 명렁어 를좀더 자세히 다 툰다. 여 기에서 는워킹 디롁 토리와 Staging Area 

로어떤 브 탠치를 통째로 넣을 수 있다는 것만 알면 된다. master 브 탠치로 되돌 아가서 rack—branch 를 
rack 디롁 토리에 넣 는다: 



$ git read-tree — pref ix=rack/ — u rack— branch 



그리 고나서 커밋 을하면 rack 디텍 토리는 rack 프로 젝트의 파일들 을직집 복사해 넣은 것과똑 같다. 
복사한 것과 다른 점은 브 탠치를 자 유롭게 바꿀 수있고 최신 버전의 Rack 프로 젝트의 코드를 쉽게 끌 
어 올수있 다는점 이다: 



$ git checkout rack— branch 
$ git pull 



그리고 git merge -s subtree 라 는명령 어를사 용하여 master 브 랜치와 Merge 할수있 고원하 든원하 

지 않든 간에 히스 토리도 함께 Merge 된다. 수정 내용만 Merge 하거나 커밋 메 시지를 다시 작성 하려면 

-s subtree 옵션 에다가 -squash, -no-commit 를 함께 사 용해야 한다: 



$ git checkout master 

$ git merge ―— squash -s subtree —no-commit rack_branch 
Squash commit ―— not updating HEAD 

Automatic merge went well; stopped before committing as requested 



Rack 프로 젝트의 최신 코드를 가 겨다가 Merge 했고 이제 커 밋하면 된다. 물론 반대로 하는 것도 가능 

하다. rack 디롁 토리로 이 동해서 코드를 수 정하고 rack— branch 브 랜치로 Merge 한다. 그리고 Rack 프 

로젝트 저 장소에 Push 할 수 있다. 

rack 디텍토 리오ᅡ rack— branch 브탠 치와의 차 이점도 비 교할수 있다. 일 반격인 diff 명령 은사용 할수없 
고 git diff-tree 명 렁을사 용해야 한다: 
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$ git diff-tree — p rack_branch 



또 rack 디롁토 리와저 장소의 master 브 탠치와 비 교할수 있다: 



$ git diff-tree — p rack_remote/master 



6.8 요약 

커밋과 저 장소를 꼼 꼼하게 관 리하는 도구를 살펴보 았다. 문제가 생기면 바로 누가, 언제， 무엇을 했는 

지 찾 아내야 한다. 그리고 프로 젝트를 포개고 심을 때 사 용하는 방 법들도 배 웠다. 이제 Git 명 렁어는 거 
의 모두 배운 것 이다. 독 자들이 하 루빨리 익숙 해져서 자 유롭게 사용 했으면 좋 겠다. 
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지 금까지 Git 이 어렇게 동 작하고 Git 을 어떻게 사용 하는지 설명 했다. 이제 Git 을 좀 더 쉽고 편하게 사 
용할 수 있도록 도 와주는 도구를 살펴 본다. 이 장 에서는 먼저 많이 쓰이는 설정 그리고 흑 시 스템을 먼 
겨 설명 한다. 그 후에 Git 을 내게 맞추어 (Customize) 본다. Git 을 자신의 프로 젝트에 맞추고 편하게 
사용 하자. 



7.1 Git 설 정하기 

1 장에서 설명했 지만, 제일 먼저 해야하 는것은 git config 명 렁으로 이름과 e—mail 주 소를설 정하는 
것 이다: 

$ git config —global user. name "John Doe" 

$ git config —global user. email j ohndoe@example . com 



이렇게 설 정하는 것들 중에서 중요한 것을 s 가지 설명 한다. 

아주 기 초격인 설정은 1 장 에서도 설명했 지만， 이번 장에서 다시 한 번 복습 한다. Git 은 내장된 기본 규 

칙 따르지 만， 설정된 것이 있으면 그에 따 른다. Git 은 먼저 /etc/gitconf ig 파일을 찾 는다. 이 파일은 해 
당시 스템에 있는 모든사 용차와 모든저 장소에 격용되 는설정 파일 이다. git config 명령에 -system 
옵션 을주면 이파일 을사용 한다. 

다음 으로〜 /.gitconfig 파 일을찾 는다. 이 파일 은해당 사용자 에게만 적용되 는설정 파일이 다. -global 
옵션을 주면 Git 은 이 파일을 사용 한다. 

마지 막으로 현재 작업 중인 저 장소의 Git 디텍 토리에 있는 .git/config 파일을 찾 는다. 이 파일은 해 
당 겨장 소에만 적용 된다. 각 설정 파일에 중복된 설정이 있으면 설명한 순 서대로 덮어 쓴다. 예를 들어 
.git/config 와 /etc/gitconfig 에 같은 설정이 들어 있다면 .git/config 에 있 는설정 을사용 한다. 설정 
파일 은손으 로직집 편집해 도되지 만보통 git config 명렁을 사용하 는것이 더 편 하다. 

7.1.1 클 라이언 트설정 

설 정은클 라이언 트와서 버로나 뉜다. 대부분 은개인 작업환 경과관 련된클 라이언 트설정 이다. Git 에 
는 설정 거리가 매우 많 은데， 여 기서는 Workflow 를 관 리하는 데 필요한 것과 잘 사 용하는 것만 설명한 
다. 한 번도 겪지 못할 상황 에서나 유용한 옵 선까지 다 포 함하면 설정할 게 너무 많다. Git 버 견마다 옵 
션이 조금씩 다 른데, 아래와 같이 실 행하면 설치한 버: 전에서 사용할 수 있는 옵션을 모두 보여 준다: 
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$ git config —help 

어떤 옵 션을사 용할수 있는지 git config 의 에 자세히 설명돼 있다. 
core-editor 

Git 은 편 집기를 설 정하지 않 았거나 설정한 편 집기를 찾을 수 없으면 Vi 를 실행 한다. 커밋할 때나 tag 

메 시지를 편집할 때 설정한 편 집기를 실행 한다. code. editor 설 정으로 편 집기를 설정 한다: 

$ git config —global core. editor emacs 

이렇게 설 정하면 메 시지를 편집할 때 환경 변수에 설정한 편 집기가 아니라 Emacs 를 실행 한다. 
commit.template 

커 밋할때 Git 이보 여주는 커밋메 시지는 이옵션 에설정 한템플 릿파일 이다. 예 를들어 $H0ME/. gitmessage.txt 
파일을 아래와 같이만 든다: 

subject line 
what happened 
[ticket: X] 

이 파일을 commit. template 에 설 정하면 Git 은 git commit 명렁이 실행 하는편 집기에 이 메시지 를기본 
으로 넣어 준다: 

$ git config —global commit.template $H0ME/ .gitmessage.txt 
$ git commit 




그러면 commit 할 때 아래와 같은 메 시지를 편 집기에 자 동으로 채워 준다: 

subject line 
what happened 
[ticket: X] 

# Please enter the commit message for your changes . Lines starting 

# with ■#■ will be ignored, and an empty message aborts the commit. 
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# On branch master 

# Changes to be committed: 

# (use "git reset HEAD <f ile>. . . " to unstage) 

# 

# modified: lib/test. rb 
M .git/COMMIT_EDITMSG" 14L, 297C 

소속 팀에 커밋 메시지 규칙이 있으면 그 규칙에 맞는 템플릿 파일을 만 든다. Git 이 그 파일을 사 용하도 
록 설 정하면 규칙을 따 르기가 쉬워 진다. 

core, pager 

Git 은 log 나 dif f 같은 명렁의 메 시지를 출력할 때 페 이지로 나누어 보여 준다. 기 본으로 사 용하는 명령 
은 less 다. more 를 더 좋 아하면 more 라고 설정 한다. 페 이지를 나누고 싶지 않으면 빈 문 자열로 설정 한다: 

$ git config —global core. pager 



이 명렁을 실 행하면 Git 은 길든지 짧든지 결 고ᅡ를 한 번에 다 보여 준다. 

user.signingkey 

2 장에서 설 명했던 Annotated Tag 를 만들 때 유용 하다. 사용할 GPG 키를 설정해 둘 수 있다. 아래 처 
럼 GPG 키를 설 정하면 서명할 때 편리 하다: 

$ git config —global user.signingkey <gpg-key-id> 



git tag 명렁을 실행할 때 키를 생 락하고 서명할 수 있다: 

$ git tag -s <tag-name> 



core.excludesfile 

Git 이 무 시하는 untracked 파일은 .gitignore 에 해당 패턴을 적으면 된다고 2 장에서 설명 했다. 해 
당 패턴의 파일은 git add 명 령으로 추 가해도 Stage 되지 않 는다. .gitignore 파일을 저장소 밖에 두 
고 관 리하고 싶으면 core.excludesfile 에 해당 파일의 경로를 설정 한다. 이 파일을 작 성하는 방법은 
.gitignore 파일을 작 성하는 방법과 같다. 그리고 core.excludesfile 에 설정한 파일과 겨장소 안에 있는 
.gitignore 파 일은들 다사용 된다. 
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help.autocorrect 

이 옵션은 Git 1 .6. 1 버 견부터 사용할 수 있다. 명 령어를 잘못 입 력하면 Git 은 메 시지를 아래와 같이 보 
여 준다: 

$ git com 

git: 'com' is not a git— command. See 'git ―— help' . 

Did you mean this? 
commit 



그러나 help.autocorrect 를 1 로 설 정하면 명 렁어를 잘못 입 력해도 Git 이 자 동으로 해당 명 령어를 찾아 
서 실행해 준다. 단, 해당 명 령어가 딱 하나 찾았을 때에만 실행 한다. 

7.1.2 걸러 터미널 

사람이 쉽게 인식 할수있 도록터 미널에 결 과를컬 러로출 력할수 있다. 터미널 컬러와 관련된 옵선은 
매우 다 양하기 때문에 꼼 꼼하게 설정할 수 있다. 

color.ui 

color. ui 를 true 로 설 정하면 Git 이 알아서 결과에 색칠 한다. 물 론무엇 을어떤 색으로 칠할지 꼼 꼼하게 
설정 할수있 지만, 이 옵션을 켜면 터미널 을그낭 기본 컬러로 칠 한다. 

$ git config —global color.ui true 



이 옵션 을켜면 Git 은터 미널에 컬러로 결고ᅡ 를출력 한다. 이 값을 false 로설 정하면 결대 컬러로 출력하 
지 않 는다. 결과를 파일로 리다 이텍트 하거나 다른 프로그 램으로 보낼 (Piping. 파이프 라인) 때도 그렇 
다. 

color.ui = always 라고설 정하면 결고 ᅡ를리 다이롁 트할때 에도걸 러코드 가출력 된다. 이렇 게까지 설정 
해야 하는 경우는 매우 드 물다. 대신 Git 명 렁에는 -color 옵선이 있어서 어떻게 출 력할지 그 때그때 정 
해줄수 있다. 보통은 color.ui = true 만으로 도충분 하다. 

color.* 

Git 은 좀 더 꼼 꼼하게 컬러를 설 정하는 방법을 제공 한다. 아래와 같은 설 정들이 있다. 모두 true, false, 
always 중 하나를 고를수 있다: 

color. branch 
color. diff 
color. interactive 
color. status 
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또한, 각 옵션의 컬러를 직집 지정할 수도 있다. 아 래처럼 설 정하면 diff 명 렁에서 meta 정보의 포그라 
운드는 blue, 백그라 운드는 black, 테 스트는 bc)ld 로 바 뀐다: 



$ git config —global color. diff .meta "blue black bold 



걸러는 normal, black, red, green, yellow, blue, magenta, cyan, white 중에서 고를 수 있고 텍 
스트 속성은 bold, dim, ul, blink, reverse 중에서 고를 수 있다. 
git config 맨 페이지 를보면 어떤 설정 거리가 있는지 자세히 나 온다. 

7.1.3 다른 Merge, Diff 도구시 용하기 

Git 에 들어 있는 diff 말고 다른 도구로 바꿀수 있다. 화려한 GUI 도구로 바꿔서 좀 더 편 리하게 충돌을 
해 결할수 있다. 여 기서는 Perforce 의 Merge 도구인 P4Merge 로설정 하는것 을보여 준다. P4Merge 
는무 료인데 다폐괜 찮다. 

P4Merge 는 중요 플 랫폼을 모두 지 원하기 때문에 웬만한 환 경이면 사용할 수 있다. 여 기서는 Mac 과 

Linux 시 스템에 설 치하는 것을 보여 준다. 윈 도에서 사용 하려면 /usr/local/bin 경로만 윈도 경로로 바 

꿔 준다. 

다 음페이 지에서 P4Merge 를 내려받 는다: 



http ： //www . perforce . com/product/components/ perforce— visual—merge— and— diff —tools 



먼겨 P4Merge 에 쓸 Wrapper 스크 립트를 만 든다. 필자는 Mac 사용 자라서 Mac 경로를 사용 한다. 
어떤 시스 템이든 Emerge 가 설치된 경 로를사 용하면 된다. extMerge 라는 Merge 용 Wrapper 스크립 
트를 만들고 이 스크 립트로 님 어오는 모든 아규 먼트를 p4merge 프로그 램으로 님 긴다: 

$ cat /usr/local/bin/extMerge 
#!/bin/sh 

/Applications/p4merge.app/Contents/MacOS/p4irierge $* 



그리고 diff 용 Wrapper 도 만 든다. 이 스크 립트로 님 어오는 아규 먼트는 충 7 개지만 그 중 2 개만 
Merge Wrapper 로 님 긴다. Git 이 diff 프로 그램에 님겨주 는아규 먼트는 아래와 같다: 



path old-file old-hex old-mode new-file new-hex new-mode 




이 중에서 old-file 과 new-file 만사 용하는 wrapper script 를 만 든다: 



$ cat /usr/local/bin/extDiff 
#!/bin/sh 

[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5 
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이 두 스크 립트에 실행 권한을 부여 한다: 

$ sudo chmod +x /usr/local/bin/extMerge 
$ sudo chmod +x /usr/local/bin/extDiff 



Git COnfig 파일에 이 스크 립트를 모두 추가 한다. 설 정해야 하는 옵션이 좀 많다. merge, tool 로 무슨 
Merge 도구 를사용 할지, mergetool . * . aid 로 실제로 어떻게 명령어 를실행 할지, mergetool . trustExitCode 로 

Merge 도구가 반 환하는 exit 코드가 merge 의 성공 여부를 나타내 는지， diff. external 은 diff 할 때 실 
행할 명 렁어가 무엇 인지를 설정할 때 사용 한다. 모두 git config 명 령으로 설정 한다: 

$ git config —global merge. tool extMerge 

$ git config —global mergetool . extMerge . cmd \ 

'extMerge M $BASE" "$ LOCAL" "$REM0TE" "$MERGED'" 
$ git config —global mergetool •trustExitCode false 
$ git config ― global diff .external extDiff 

〜/ . gitconfig/ 파일을 직집 편 집해도 된다: 

[merge] 

tool = extMerge 
[mergetool "extMerge" ] 

and = extMerge \"$BASE\" \"$L0CAL\" \"$REM0TE\" \"$MERGED\" 

trustExitCode = false 
[diff] 

external = extDiff 



설정을 완 료하고 나서 아래와 같이 diff 명 렁어를 실행 한다: 

$ git diff 32d1776b1 A 32d1776b1 

diff 결고 ᅡ가터 미널에 출 력되는 대신 P4Merge 가실행 된다. 그리 고그림 귀처 럼그프 로그램 안에서 
보여 준다: 

브 탠치를 Merge 할 때 충돌이 나면 git mergetool 명령을 실행 한다. 이 명렁을 실 행하면 GUI 도구로 

충돌을 해결할 수 있도록 P4Merge 를 실행해 준다. 

Wrapper 를 만들어 설정 해두면 다른 diff, Merge 도 구로바 꾸기도 쉽다. 예를 들어， KDiff3 를 사용하 
도록 extDiff 와 extMerge 스크 립트를 수정 한다: 

$ cat /usr/local/bin/extMerge 
#!/bin/sh 

/Applications/kdiff3.app/Contents/MacOS/kdiff3 $* 
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그림 7.1: P4Merge 



이 제부터 Git 은 diff 결과를 보여 주거나 충돌을 해결할 때 KDiff3 도구를 사용 한다. 
어떤 Merge 도구는 Git 에 미리 cmd 설정 이들어 있다. 그래서 cmd 설정 없이 사용할 수있는 것도있 
다. kdiff3, opendiff, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff 는 cmd 설정 없이 Merge 
도구로 사용할 수 있다. diff 도 구로는 다른 것을 사용하 지만, Merge 도 구로는 KDiff3 를 사 용하고 싶 
은 경 우에는 kdiff3 명렁을 실행 경로로 넣고 아래와 같이 설정 하기만 하면 된다: 



$ git config —global merge. tool kdiff3 



extMerge 와 extDiff 파 일을사 용하지 않고 이렇게 Merge 도구만 kdiff3 로 설 정하고 diff 도구는 Git 
에 원래 들어 있는 것을 사용할 수 있다. 

7.1.4 소 스포맷 과공백 

협업할 때 겪는 소스 포맷 (Formatting) 과 공백 문제는 미 요하고 난해 하다. 동료 사이에 사 용하는 플 
랫폼이 다를때 는특히 더 심 하다. 다른 사람이 보내온 Patch 는공백 문자 패턴이 미 요하게 다를 확를이 
높다. 편집기 가몰래 공백 문자를 추가해 버릴 수도 있고크 로스- 플랫폼 프로젝 트에서 윈 도개발 자가줄 
끝에 CR(Carriage-Return) 문자를 추가해 버렸 을수도 있다. Git 에는 이 이슈를 돕는몇 가지 설정이 
있다. 

core.autocrlf 

윈 도에서 개발하 는동료 와함께 일하면 줄 바꿈 (New Line) 문자에 문 제가생 긴다. 윈 도는줄 바꿈문 
자로 CR(Carriage-Return) 과 LF(Line Feed) 문자를 들 다 사용하 지만， Mac 과 Linux 는 LF 문자만 
사용 한다. 아 무것도 아닌 것 같 지만， 크로스 플랫폼 프 로젝트 에서는 폐 성가신 문 제다. 
Git 은 커밋할 때 자 동으로 CRLF 를 LF 로 변환 해주고 반대로 Checkout 할 때 LF 를 CRLF 로 변환해 
주는 기능이 있다. core.autocrlf 설정 으로이 기능 을켤수 있다. 윈 도에서 이 값을 true 로설 정하면 
Checkout 할 때 LF 문자가 CRLR 문자로 변환 된다: 



$ git config —global core.autocrlf true 



179 



7 장 Git 맞춤 



Scott Chacon Pro Git 



줄 바꿈 문자로 LF 를 사 용하는 Linux 와 Mac 에서는 Checkout 할 때 Git 이 LF 를 CRLF 로 변환할 필요 
가 없다. 게다가 우연히 CRLF 가 들어간 파일이 저 장소에 들어 있어도 Git 이 알아서 고 처주면 좋 을것이 
다. core.autocrlf 값을 input 으로 설 정하면 커밋할 때만 CRLF 를 LF 로 변환 한다: 

$ git config —global core.autocrlf input 



이 설정을 이 용하면 윈도 에서는 CRLF 를 사 용하고 Mac, Linux, 저장소 에서는 LF 를 사용할 수 있다. 
윈도 플랫폼 에서만 개 발하면 이 기능이 필요 없다. 이 옵션을 false 라고 설 정하면 이 기능이 꺼지고 CR 
문 자도저 장소에 도저장 된다: 



$ git config —global core.autocrlf false 



core.whitespace 

Git 에는 공백 문자를 다루는 방 법으로 네 가지가 미리 정의돼 있다. 두 가지 는기본 적으로 켜겨 있지만 
끌 수있고 나머지 두 가지는 끼져 있지만 켤 수 있다. 

먼저 기본 격으로 켜겨 있는 것을 살펴 보자. trailing-space 는 각 줄 끝에 공백이 있는지 찾고 space- 
bef ore-tab 은 모든줄 처음에 tab 보다 공백이 먼겨 나 오는지 찾 는다. 

기본 격으로 끼져 있는 나머지 두 개는 indent— with— non— tab 과 cr— at— eol 이다. intent— with-non— tab 은 
tab 이 아니라 공백 8 자이 상으로 시 작하는 줄이 있는지 찾고 cr-at-eol 은 줄 끝에 CR 문자가 있어도 괜 
찮다고 Git 에알 리는것 이다. 

core.whitespace 옵 션으로 이 네 가지 방법을 켜고 끌 수 있다. 설 정에서 해당 옵션을 빼 버리거 나이름 
이 -로시 작하면 기능이 끼 진다. 예를 들어, 다른건 다켜고 cr-at-eol 옵션 만끄려 면아래 와같이 설정 
한다: 



$ git config —global core.whitespace \ 

trailing-space, space-bef ore-tab, indent-with-non-tab 



git diff 명렁을 실 행하면 Git 은 이 설정에 따라 검 사해서 컬러로 표시해 준다. 그래서 좀 더 쉽게 검토 
해서 커밋할 수 있다. git apply 명 령으로 Patch 를 적용할 때도 이 설정을 이용할 수 있다. 아 래처럼 명 
렁어를 실 행하면 해당 Patch 가공 백문자 정책에 들어 맞는지 확인할 수 있다: 



$ git apply — whitespace=warn <patch> 



아니면 Git 이 자 동으로 고 치도록 할 수 있다: 



$ git apply — whitespace=fix <patch> 



이 옵션은 git rebase 명렁 에서도 사용할 수 있다. 공백 문제가 있는 커밋을 서버로 Push 하기 견에 -- 
whites P ace=fix 옵션을 주고 Rebase 하면 Git 은 다시 Patch 를 격용 하면서 공백을 설정한 대로 고 친다. 
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7.1.5 서 버설정 

서버 설정은 많지 않 지만， 꼭 겊고 님 어가야 하는 것 이몇개 있다. 
receive.fsckObjects 

Git 은 Push 할 때 기본 적으로 개체를 검 증하지 (check for consistency) 않 는다. 하 지만, Push 할 때 
마다각 개체가 SHA-1 체 크섬에 맞 는지, 잘못된 개 체가가 리키고 있는지 검 사하게 할수 있다. 개체 
를점검 하는것 은상대 적으로 느려서 Push 하는 시간이 늘어 난다. 얼마나 늘어나 는지는 저장소 크기와 
Push 하 는양에 달 렸다. receive. fsckOBjects 값을 true 로설 정하면 Git 이 Push 할때마 다검증 한다. 



$ git config —system receive.fsckObjects true 

이렇게 설 정하면 Push 할 때마다 검 증하기 때문에 클라이 언트는 잘못된 데 이터를 Push 하지 못 한다. 
receive.denyNonFast Forwards 

이미 Push 한 커밋을 Rebase 해서 다시 Push 하지 못하게 할 수 있다. 브 탠치를 Push 할 때 해당 리모 
트브탠 치가가 리키는 커밋이 Push 하 려는브 랜치에 없을때 Push 하 지못하 게할수 있다. 보통 은이런 
정책이 좋고 git push 명령에 -f 옵션을 주면 강제로 Push 할 수 있다. 

하 지만, 강제로 Push 하지 못하게 할 수도 있다. receive. denyNonFastForwards 옵션을 켜면 Fast— 

forward 로 Push 할 수 없는 브 탠치는 아예 Push 하지 못 한다: 



$ git config —― system receive . denyNonFastForwards true 



사용 자마다 다른 정책을 적 용하고 심으면 서버 흑을 사 용해야 한다. 서버의 receive 흑으로 할 수 있고 
이흑도 이장에 서설명 한다. 

receive.denyDeletes 

receive. denyNonFastForwards 와비 숫한정 책으로 receive. denyDeletes 라 는것이 있다. 이 설정 을켜면 

브 탠치를 삭 제하는 Push 가 거결 된다. Git 1.6.1 부터 receive, deny Deletes 를 사용할 수 있다: 



$ git config —― system receive.denyDeletes true 



이제 브 랜치나 Tag 를 삭 제하는 Push 는 거절 된다. 아무도 삭제할 수 없다. 리모트 브 탠치를 삭 제하려 
면 직접 손으로 server 의 ref 파 일을삭 제해야 한다. 그리고 사용자 마다다 른정책 을격용 시키는 ACL 
을 만드는 방법도 있다. 이 방법은 이 장 끝 부 분에서 다 툰다. 

7.2 Git Attribute 

디 텍 토리와 파일 단위로 다른 설정을 적용할 수도 있다. 이렇게 경 로별로 설 정하는 것을 'Git At- 
tribute' 라고부 른다. 이 설정은 .gitattributes 라는 파일에 저장하 고아무 디텍토 리에나 둘수있 지만, 
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보통은 프 로젝트 최상위 디텍 토리에 둔다. 그리고 이 파일을 커 밋하고 싶지 않으면 .gitattributes 가 아 
니라 .git/info/attributes 로 파일을 만 든다. 

이 Attribute 로 Merge 는 어떻게 할지, 텍 스트가 아닌 파일은 어떻게 Diff 할지, checkin/checkout 
할 때 어떻게 필터 링할지 정해줄 수 있다. 이 결 에서는 설정할 수 있는 Attribute 가어떤 것이 있 는지, 
그리고 어떻게 설정 하는지 배우고 예제를 살펴 본다. 

7.2.1 바이너 리파일 

이 Attribute 로어떤 파일이 바 이너리 파 일인지 Git 에게 알려줄 수 있다. 기본 격으로 Git 은어떤 파일 
이 바 이너리 파 일인지 알지 못 한다. 하 지만, Git 에는 파일을 어떻게 다뤄야 하는지 알 려주는 방법이 있 
다. 텍스 트파일 중에서 프로 그램이 생성 하는파 일에는 바 이너리 파 일과진 배없는 파일이 있다. 이런 파 
일은 diff 할 수 없으니 바 이너리 파일 이라고 알 려줘야 한다. 반대로 바 이너리 파일 중에서 취급 방법을 
Git 에 알 려주면 diff 할 수 있는 파일도 있다. 

바 이너리 파일이 라고알 려주기 

사실 텍스트 파일이 지만만 든목적 과의도 를보면 바 이너리 파일인 것이 있다. 예 를들어 Mac 의 Xcode 
는 .pbxproj 파일을 만 든다. 이 파일은 IDE 설정 등을 디 스크에 저 장하는 파일로 JSON 포맷 이다. 모든 
것이 ASCII 인 텍스 트파일 이지만 실제로 는간단 한데이 터베이 스이기 때문에 텍 스트파 일처럼 취급할 
수 없다. 그래서 여러 명이이 파일을 동시에 수 정하고 Merge 할 때 diff 가 도움이 안 된다. 이 파일은 프 
로 그램이 읽고 쓰는파 일이기 때문에 바 이너리 파 일처럼 취 급하는 것이 옳다. 

모든 Pbxproj 파일을 바이너 리로파 일로취 급하는 설정은 아래와 같다. .gitattributes 파일에 넣으면 
된다: 



*.pbxproj -crlf -diff 



이제 pbxproj 파일은 CRLF 변환이 격 용되지 않 는다. git show 나 git diff 같은 명령을 실행할 때에도 
통게를 계산 하거나 diff 를 출 력하지 않 는다. Git 1 .6 부터는 -crlf -diff 를 한 마디로 줄여서 표현할 수 
있다: 



. pbxproj binary 



바이너 리파일 Diff 하기 

Git 은바 이너리 파일도 diff 할수 있다. Git Attribute 를통해 Git 이 바 이너리 파일을 텍 스트포 맷으로 
변 환하고 그 결과를 diff 로 비교 하도록 하는 것 이다. 그래서 문제는 어떻게 바이 너리를 텍 스트로 변환 
해야 할까에 있다. 바이 너리를 텍 스트로 변환해 주는 도구 중에서 내가 필요한 바 이너리 파일에 꼭 맞는 
도구를 찾는게 가장 좋다. 사람이 읽을 수 있는 텍 스트로 표현된 바 이너리 포맷은 극히 드물다 (오 디오 
데 이터를 텍 스트로 변환 한다고 생각 해보라 ). 파일 내용을 텍 스트로 변환할 방법을 찾지 못했을 때는 파 
일의 설 명이나 메타데 이터를 텍 스트로 변 환하는 방법을 찾아 보자. 이런 방법이 가능한 경우가 많다. 메 
타데 이터는 파일 내용을 완 벽하게 알 려주지 않지만 전혀 비 교하지 못하는 것보다 이렇 게라도 하는 게 
휠썬 낫다. 

여기서 설명한 두 가지 방법을 많이 사용 하는바 이너리 파일에 적용해 볼 거다. 
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댓글: 전용 변 환기는 없지만 텍스트 가들어 있는 바 이너리 포 맷들이 있다. 이런 포맷은 strings 프로그 
램으로 바 이너리 파 일에서 텍스트 를추출 한다. 이런 종류의 바 이너리 파일 중에서 UTF—16 인 코딩이 
나 다른 "codepages" 로 된 파 일들도 있다. 그런 인코 딩으로 된 파 일에서 strings 으로 추출할 수 있는 
텍 스트는 제한격 이다. 상황에 따라 다르게 추출 된다. 그래도 strings 는 Mac 과 Linux 시스 템에서 쉽게 
사용할 수있기 때문에 다 양한바 이너리 파일에 쉽게 적 용할수 있다. 

MS Word 파일 먼저 이 기술을 인 류에게 알려진 가장 귀찮은 문제 중 하나인 Word 문서를 버견 관리 
하는 상황을 살펴 보자. 모든 사람이 Word 가가장 끔찍한 편집 기라고 말 하지만 애석 하게도 모두 Word 
를사용 한다. Git 저 장소에 넣고 이따금 커밋하 는것만 으로도 Word 문서의 버 견을관 리할수 있다. 그 
렇지만 git dif f 를 실 행하면 다음과 같은 메 시지를 볼 수있을 뿐 이다: 

$ git diff 

diff —git a/chapter1 .doc b/chapter1 .doc 
index 88839c4. .4afcb7c 1 00644 

Binary files a/chapterl .doc and b/chapter1 .doc differ 



직집 파일을 하 나하나 까보지 않으면 두 버견이 뭐가 다른지 알 수 없다. Git Attribute 를 사 용하면 이 
를 더 좋게 개선할 수 있다. .gitattributes 파일에 아래와 같은 내용을 추가 한다: 



★.doc diff=word 



이것은 *.d 0C 파일의 두 버전이 무엇이 다른지 diff 할 때 "word" 필터 를사용 하라고 설 정하는 것 이다. 
그럼 "word" 필터는 뭘까? 이 "word" 필터도 정 의해야 한다. Word 문 서에서 사람이 읽을 수 있는 
텍 스트를 추출 해주는 catdoc 프로 그램을 "word" 필터로 사용 한다. 그러면 Word 문서를 diff 할 수 있 

다. (catdoc 프로 그램은 MS Word 문서에 특화된 텍스 트추출 기다. http://www.wagner.pp.ru/~vitus/ 
software/catdoc/ 에서 구할 수 있다) ： 



$ git config diff .word. textconv catdoc 



위의 명령은 아래와 같은 내용을 .git/conf ig 파일에 추가 한다: 



[diff "word" ] 

textconv = catdoc 



이제 Git 은확 장자가 .doc 인 파일의 스 냅샷을 diff 할때 "word" 필터로 정의한 catdoc 프 로그램 을사용 
한다. 이 프로 그램은 Word 파일을 텍스트 파일로 변환해 주기 때문에 diff 할 수 있다. 
이책으 ᅵ 1 장을 Word 파일로 만 들어서 Git 에 넣고 나서 단락 하나를 수 정하고 겨 장하는 예를 살펴 보자. 
git diff 를 실 행하면 어디가 달려 쳤는지 확인할 수 있다: 



183 



7 장 Git 맞춤 



Scott Chacon Pro Git 



$ git diff 

diff —git a/chapter1 .doc b/chapter1 .doc 

index c1c8a0a. ,b93c9e4 100644 

— a/chapter1 .doc 

+++ b/chapter1 .doc 

m -128,7 +128,7 @@ and data size) 
Since its birth in 2005, Git has evolved and matured to be easy to use 
and yet retain these initial qualities. It ' s incredibly fast, it ' s 
very efficient with large projects, and it has an incredible branching 

-system for non-linear development. 

+system for non-linear development (See Chapter 3) . 



Git 은 "(See Chapter 3)" 가 추가 됐다는 것을 정 확하게 찾아 준다. 

OpenDocument 파일 MS Word (*. doc) 파일에 사용한 방법은 OpenOffice.org (흑은 LibreOf- 
fice.org) 파일 형식인 OpenDocument (*.odt) 파 일에도 격용할 수 있다. 

아래의 내용을 .gitattributes 파일에 추가 한다: 
*.odt diff=odt 



.git/config 파일에 odt diff 필터를 설정 한다: 

[diff "odt"] 

binary = true 

textconv = /usr/local/bin/odt-to-txt 



OpenDocument 파일 은사실 여러 파일 (XML, 스 타일, 이미지 등등) 을 Zip 으 로압축 한형식 이다. 
OpenDocument 파 일에서 텍 스트만 추 출하는 스크 립트를 하나 작성 한다. 아래와 같은 내용을 /usr/ 

local/bin/odt-to-txt 파일로 (다른 위치에 저장해 도상관 없다) 저장 한다: 

#! /usr/bin/env perl 

# Simplistic OpenDocument Text ( .odt) to plain text converter. 

# Author: Philipp Kempgen 

if (！ defined($ARGV[0])) { 

print STDERR "No filename given !\n"; 
print STDERR "Usage: $0 filenameXn" ； 
exit 1; 

} 
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■unzip ᄂ 1 -qq 1 , ■— p ᄂ $ARGV[0] , 1 content. xml" or die $!; 



my $content = 1 
open my $fh x '― 

{ 

local $/ = undef ； # slurp mode 
$content = <$fh>; 

} 

close $fh; 
$_ = $content; 

s/<text :span\b[ A >]*>//g; # remove spans 

s/Ctext:h\b[ A 〉 ᅵ *〉/\n\n***** /g; # headers 
s/<text:list-item\b[ A >]*>\s*<text:p\b[ A >]*>/\n 
s/<text:list\b[ A >]*>/\n\n/g; 
s/<text:p\b[ A >]*>/\n /g; 
s/<[ A >]+>//g; 
s/\n{2,}/\n\n/g; 
s/\A\n+//; 

print "\n", $ ―, "\n\n"; 



/g; # list items 



# lists 

# paragraphs 

# remove all XML tags 

# remove multiple blank lines 

# remove leading blank lines 



그리 고실행 가능하 도록만 든다: 




이제 git diff 명 령으로 .odt 파 일에대 한변호 ᅡ를살 펴볼수 있다. 



이미 지파일 이방 법으로 이미지 파일도 diff 할수 있다. 필터로 EXIF 정 보를추 출해서 PNG 파일을 
비교 한다. EXIF 정보는 대 부분의 이미지 파일에 들어 있는 메 타데이 터다. exif tool 이라 는프로 그램을 
설 치하고 이미지 파 일에서 메타 데이터 텍스트 를추출 한다. 그리 고그결 고ᅡ를 diff 해서 무엇이 달 라겼는 
지 본다: 



$ echo '*.pngdiff=exif' » .gitattributes 
$ git config diff .exif .textconv exiftool 



프로 젝트에 들어 있는 이미지 파일을 변 경하고 git diff 를 실 행하면 아래와 같이 보여 준다: 



diff ― git a/image . pngb/ image . png 
index 88839c4. .4afcb7c 100644 
— a/image. png 
+++ b/image.png 
@@ —1,12 +1,12 @@ 
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ExifTool Version Number 
-File Size 

-File Modification Date/Time 
+File Size 

+File Modification Date/Time 

File Type 

MIME Type 
-Image Width 
-Image Height 
+Image Width 
+Image Height 

Bit Depth 

Color Type 



7.74 
70 kB 

2009：04：17 10:12:35—07:00 
94 kB 

2009：04：21 07： 02： 43-07： 00 
PNG 

image/png 

1058 

889 

1056 

827 

8 

RGB with Alpha 



이미지 파일의 크기와 해 상도가 달라진 것을 쉽게 알 수 있다: 



7.2.2 키워 드치환 

SVN 이나 CVS 에 익숙 한사람 들은해 당시스 렘에서 사 용하던 키워 드치환 (Keyword Expansion) 기 
능을 찾 는다. Git 에서는 이것이 쉽지 않다ᅳ Git 은 먼저 체 크섬을 계 산하고 커 밋하기 때문에 그 커밋에 
대한 정보를 가지고 파일을 수정할 수 없다. 하 지만， Checkout 할 때 그 정 보가자 동으로 파일에 삽입 
되도록 했다가 다시 커밋할 때 삭제 되도록 할 수 있다. 

파일 안에 $id$ 필드를 넣으면 Blob 의 SHA-1 체 크심을 차동으 로삽입 한다. 이 필드를 파일에 넣으면 
Git 은 앞으로 Checkout 할 때 해당 Blob 의 SHA-1 값으로 교체 한다. 여기서 꼭 기 억해야 할 것이 있 
다. 교체 되는체 크섬은 커밋의 것이 아니라 B ᅵ ob 그자 체의 SHA-1 체크섬 이다: 



$ echo '*.txt ident' » .gitattributes 
$ echo '$Id$' > test.txt 




Git 은 이 파일을 Checkout 할 때마다 SHA 값을 삽입해 준다: 



$ rm test.txt 

$ git checkout ―— test.txt 
$ cat test.txt 

$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $ 



하지만 이것은 별로 유 용하지 않다. CVS 나 SVN 으 | 키워드 치환 (Keyword Substitution) 을 써봤으 
면 날짜 (Datestamp) 도 가능 했다는 것을 알고 있을 것 이다. SHA 는 그낭 해 시이고 식별할 수 있을뿐 
이지 다른 것을 알 려주진 않 는다. SHA 만 으로는 예견 것보다 새 것인지 오래된 것 인지는 알 수 없다. 
Commit/Checkout 할 때 사 용하는 필터 를직집 만들어 쏠 수 있다. 방향에 따라 "clean" 필터와 
"smudge" 필 터라고 부 른다. ".gitattributes" 파일에 설 정하고 파일 경 로마다 다른 필터를 설정할 수 

186 



Scott Chacon Pro Git 



2 절 Git Attribute 



있다. Checkout 할때 파일을 처리하 는것이 "smudge" 필 터이고 (그림 7-2) 커 밋할때 처리 하는필 
터가 "dean" 필터 이다. 이 필터로 할 수 있는 일은 무 긍무진 하다. 



Staging Area 



Working Directory 





*.txt Filter 




fileA.txt 






smudge 






flleiUxr 




















fileB.txt 






cl6&n 






flleB ᅳ txT 









fjleC.rb 




ffleC.rb 





git checkout 
그림 7.2: "smudge" 필터는 Checkout 할 때 실 행된다 



Staging Area 



Working Directory 



fileA.txt 



fileB.txt 



•txt Filter 



clean 



시 



fileB.txt' 



fjleC.rb 




flleC.rb 





git add 

그림 7.3: "clean" 필터는 파일을 Stage 할 때 실 행된다 

커 밋하기 전에 indent 프로그 램으로 C 코드 전부를 필터링 하지만 커밋 메 시지는 단순한 예제를 보자. 
*.c 파일은 indent 필터 를사용 하도록 .gitattributes 파일에 설정 한다: 

*.c f ilter=indent 

아 래처럼 "indent" 필터의 smudge 와 dean 이 무 엇인지 설정 한다: 

$ git config —― global filter. indent. clean indent 
$ git config —global filter . indent . smudge cat 



*.c 파 일을커 밋하면 indent 프로 그램을 통해서 커 밋되고 Checkout 하면 cat 프 로그램 을통해 
Checkout 된다. cat 은 입력된 데 이터를 그대로 다시 내보 내는, 사실 아 무것도 안 하는 프 로그램 이다. 

이렇게 설 정하면 모든 C 소스 파일은 indent 프로 그램을 통해 커밋 된다. 

이제 RCS 처럼 $0하6$를 치환하 는예제 을살펴 보자. 이것를 하려면 간단한 스크립 트가하 나필요 하다. 
이 스크 립트는 $Date$ 필드를 프로 젝트의 마지막 커밋 일자로 치환 한다. 표준 입력을 읽어서 $Date$ 필 
드를 치환 한다. 아래는 Ruby 로 구현한 스크립 트다: 
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#! /usr/bin/env ruby 
data I STDIN.read 

last— date = "git log — pretty=format: "%ad" —1、 

puts data.gsub('$Date$', '$Date: 1 + last_date.to_s + ■$■) 



git log 명 렁으로 마지막 커밋 정보를 얻고 표준 입력 (STDIN) 에서 $Date$ 스 트링을 찾아서 치환 한다. 
스크 립트는 자신이 편한 언어로 만 든다. 이 스크 립트의 이름을 expand— date 라고 칫고 실행 경로에 넣는 
다. 그리고 dater 라는 Git 필터 를정의 한다. Checkout 시 실 행하는 smudge 필터로 expand_date 를사 
용하고 커밋할 때 실 행하는 clean 1 멸터는 Perl 을 사용 한다: 

$ git config filter. dater. smudge expand— date 

$ git config filter. dater. clean 'perl -pe "s/\\\$Date[ A \\\$]*\\\$/\\\$Date\\\$/" ' 



이 Perl 코드는 $Date$ 스 트링에 있는 문자를 제 거해서 원 래대로 복원 한다. 이제 필터가 준비 됐으니 

$Date$ 키 워드가 들어 있는 파일을 만들고 Git Attribute 를 설정 한다. 새 필터를 시험해 보자: 



$ echo '# $Date$' > date_test.txt 

$ echo 'date*. txt f ilter=dater' » .gitattrib 니 tes 




커 밋하고 파일을 다시 Checkout 하면 해당 키 워드가 격절히 치환된 것 을볼수 있다: 



$ git add date— test. txt .gitattributes 

$ git commit -m "Testing date expansion in Git" 

$ rm date_test.txt 

$ git checkout date_test.txt 

$ cat date— test. txt 

# $Date: Tue Apr 21 07:26:52 2009 -0700$ 

이것은 매우 강 력해서 두루 두루사 용할수 있다. .gitattributes 파일은 커밋 하는파 일이기 때문에 드 
라이버 (여 기서는 dater) 가 없는사 람에게 도배포 된다. 그리고 dater 가 없으면 에러가 난다. 필 터를만 
들 때이런 예외 상황도 고 려해서 항상 잘 동 작하게 해야 한다. 

7.2.3 저장소 익스포 트하기 

프로 젝트를 익스포 트해서 아카 이브를 만들 때에도 Git Attribute 가 유용 하다. 
export-ignore 

아카이 브를만 들때제 외할파 일이나 디롁토 리가무 엇인지 설 정할수 있다. 특정 디텍토 리나파 일을프 

로젝 트에는 포 함하고 아카이 브에는 포 함하고 싶지 않을 때 export-ignore Attribute 를 사용 한다. 
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예 를들어 test/ 디텍 토리에 테스트 파일이 있다고 하자. 보통 tar 파일로 묶어서 익스포 트할때 테스트 
파 일은포 함하지 않 는다. Git Attribute 파일에 다음라 인을추 가하면 테스 트파일 은무시 된다: 



test/ export-ignore 



git archive 명 령으로 tar 파일을 만들면 test 디 텍토리 는아카 이브에 포 함되지 않 는다. 

export— subst 

아카 이브를 만들 때에도 키워드 치환을 할 수 있다. 파일을 하나 만들고 거기에 $F 0rm at :$ 스 트링을 넣 
으면 Git 이 치환해 준다. 이 스 트링에 --prettFformat 옵션에 사 용하는 것과 같은 포맷 코드를 넣을 수 
있다. — pretty=f ormat 은 2 장에서 배 웠다. 예 를들어 LAST— COMMIT 이라는 파일을 만들고 git archive 명 
렁을 실행할 때 자 동으로 이 파일에 마지막 커밋 날짜가 삽 입되게 하려면 아래와 같이 해야 한다: 

$ echo 'Last commit date: $Format:%cd$ ' > LAST_COMMIT 
$ echo "LAST_COMMIT export— subst" » .gitattributes 
$ git add LAST_COMMIT .gitattributes 
$ git commit —am 'adding LAST_COMMIT file for archives ' 



git archive 명 령으로 아카 이브를 만들고 나서 이 파일을 열 어보면 아래와 같이 보 인다: 
$ cat LAST_COMMIT 

Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$ 



7.2.4 Merge 전락 

파 일마다 다른 Merge 견락을 사용 하도록 설정할 수 있다. Merge 할 때 충돌이 날 것 같은 파일이 있다 

고 하자. Git Attrbute 로 이 파일만 항상 타인의 코드 말고 내 코드를 사용 하도록 설정할 수 있다. 

이 설정은 다양한 환 경에서 운영 하려고 만든 환경 브 탠치를 Merge 할 때 좋다. 이때는 환경 설정과 관 

련된 파일은 Merge 하지 않 고무시 하는게 편리 하다. 브 탠치에 database. xml 이 라는데 이터베 이스설 ; 정 

파일이 있는데 이 파일은 브탠 치마다 다 르다. Database 설정 파일은 Merge 하면 안 된다. Attribute 
를 아래와 같이 설 정하면 이 파일은 그낭 두고 Merge 한다. 

database. xml merge=ours 



이제 Merge 해도 database. xml 파일 은충 돌하지 않 는다: 

$ git merge topic 

Auto— merging database. xml 

Merge made by recursive. 



189 



7 장 Git 맞춤 



Scott Chacon Pro Git 



Merge 했지만 database. xml 은 원래 가지고 있던 파일 그대 로다. 

7.3 Git 훅 

Git 도 다른 버견 관리 시 스템처 럼 어떤이 벤트 7 ᅡ 생겼을 때 자 동으로 특정 스크 립트를 실행 하도록 할 수 
있다. 이흑은 클라이 언트흑 과서버 흑으로 나늘수 있다. 클라 이언트 흑은커 밋이나 Merge 할 때실행 
되고 서버 흑은 Push 할 때 서 버에서 실행 된다. 이 절 에서는 어떤 흑이 있고 어떻게 사용 하는지 배 운다. 

7.3.1 흑설 치하기 

흑은 Git 디 텍토리 밀에 hooks 라는 디텍 토리에 저장 한다. 기본 흑디롁 토리는 .git/hooks 이다. 이 디텍 
토리에 가보면 Git 이 자 동으로 넣어준 매우 유용한 스 크립트 예제가 S 개 있다. 그리고 스크 립트가 입 
력받는 값이 어떤 값인지 파일 안에 자세히 설명돼 있다. 모든 예제는 쉘과 Perl 스크 립트로 작성돼 있지 
만 실행할 수만 있으면 되고 Ruby 나 Python 같은 다른 스 크립트 언어로 만 들어도 된다. 예제 스 크립트 

의 파일 이 름에는 .sample 이라는 확장자 가붙어 있다. 그래서 이름 만바꿔 주면그 흑을사 용할수 있다. 
실행할 수 있는 스 크립트 파일을 저 장소의 hooks 디텍 토리에 넣으면 흑 스크 립트가 켜 진다. 이 스크립 
트는 앞으로 계속 호출 된다. 중요한 흑은 여기서 모두 설명 한다. 

7.3.2 클라이 언트흑 

클라 이언트 흑은매 우다양 하다. 이 절 에서는 클라이 언트흑 을커밋 Workflow 흑， E-mail Workflow 
흑， 그리고 나 머지로 분 류해서 설명 한다. 

커밋 Workflow 훅 

먼저 커 밋과관 련된흑 을살펴 보자. 커밋과 관련된 흑은모 두네가 지다. Pre - C0 ™it 흑 은커밋 할때가 
장 먼저 호 출되는 흑으로 커밋 메 시지를 작 성하기 전에 호출 된다. 이 흑에서 커 밋하는 Snapshot 을 점 
검 한다. 빠트린 것은 없 는지， 테 스트는 확실히 했는지 등을 검사 한다. 커밋할 때 꼭 확 인해야 할 게 있으 
면 이 흑으 로확인 한다. 그 리고이 흑의 Exit 코드가 0 이 아니면 커밋 은취소 된다. 물론 git commit - 
no-verify 라고 실 행하면 이 흑을 일시 적으로 생락할 수 있다. lint 같은 프로그 램으로 코드 스 타일을 검 
사하 거나， 줄 끝의공 백문자 를검사 하거나 (예제 로들어 있는 pre— commit 흑이 하는게 이 일이다 )， 코드 
에 주석을 달 았는지 검 사하는 일은 이 흑으로 하는 것이 좋다. 

prepare-comit-msg 흑은 Git 이 커밋 메 시지를 생 성하고 나서 편 집기를 실 행하기 견에 실행 된다. 이 흑 
은 사람이 커밋 메시 지를수 정하기 견에 먼저 프로그 램으로 손보고 싶을때 사용 한다. 이 흑 은커밋 메 
시지가 들어 있는 파일의 경로, 커밋의 종류를 아규 먼트로 받 는다. 그리고 최근 커밋을 수정할 때에는 

(Amending 커밋) SHA-1 값을 추가 아규 먼트로 더 받 는다. 사실 이 흑은 일반 커 밋에는 별로 필요 없 
고커밋 메시지 를자동 으로생 성하는 커밋에 좋다. 커밋메 시지에 템 플릿을 격용하 거나, Merge 커밋， 
Squash 커밋, Amend 커밋일 때 유용 하다. 이 스크 립트로 커밋 메시지 템 플릿에 정보를 삽입할 수 있 
다. 

commit-msg 흑은 커밋 메시지 가들어 있는 임시 파일의 경로를 아규 먼트로 받 는다. 그리고 이 스 크립트 
가 0 이 아닌 값을 반 환하면 커 밋되지 않 는다. 이 흑에서 최종 격으로 커밋이 완 료되기 전에 프 로젝트 상 

태 나커밋 메시지 를검증 한다. 이 장의 마지막 절에서 이 흑을 사용하 는예제 를보여 준다. 커밋 메시지 
가 정책에 맞는지 검 사하는 스크 립트를 만들어 보자. 

커밋이 완 료되면 post-commit 흑이 실행 된다. 이 흑은 넘 겨받는 아규 먼트가 하나도 없지만 git log -1 
HEAD 명 령으로 정보를 쉽게 가져을 수 있다. 일반 격으로 이 스크 립트는 커밋된 것을 누군 가에게 알릴 때 
사용 한다. 
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7.3 절 Git 흑 



이커밋 Workflow 스크 립트는 어떤 Workflow 에나 사용할 수 있다. 특히 정책을 강제할 때 유용 하다. 
클라 이언트 흑은 개 발자가 클 라이언 트에서 사 용하는 흑 이다. 모든 개발 자에게 유용한 흑 이지만 Clone 
할 때 복 사되지 않 는다. 그래서 직집 설 치하고 관 리해야 한다. 물론 정책을 서 버 흑으로 만들고 정책을 
잘지 키는지 Push 할 때 검 사해도 된다. 

E-mail Workflow 훅 

E-mail Workflow 에 해당하 는클라 이언트 흑은세 가지 이다. 이 흑 은모두 git am 명 렁으로 실행된 
다. 이 명령어 를사용 할일이 없으면 이 절 은읽지 않아도 된다. 하 지만， 언 젠가는 git format-patch 명 
렁으로 만든 Patch 를 E-mail 로 받는 날이 울지도 모 른다. 

제일 먼저 실행하 는흑은 applypatch— msg 이다. 이 흑의 아규 먼트는 Author 가보내 온커밋 메시지 파일 

의 이름 이다. 이 스크 립트가 종료할 때 0 이 아닌 값을 반 환하면 Git 은 Patch 하지 않 는다. 커밋 메시지 
가 규칙에 맞는지 확인 하거나 자 동으로 메 시지를 수정할 때 이 흑을 사용 한다. 

git am 으로 Patch 할때두 번째로 실행되 는흑이 pre-applypatch 이다. 이 흑은아 규먼트 가없고 단순히 

Patch 를 적 용하고 나서 실행 된다. 그래서 커밋할 스 냅샷을 검 사하는 데 사용 한다. 이 스크 립트로 테스 
트를 수 행하고 파일을 검사할 수 있다. 테 스트에 실패 하거나 뭔가 부 족하면 0 이 아닌 값을 반환 시켜서 
git am 명렁을 취소 시킬수 있다. 

git am 명 령에서 마지 막으로 실행되 는훅은 post— applypatch 다. 이 스크 립트를 이 용하면 자 동으로 

Patch 를 보낸 사 람이나 그 룹에게 알림 메 시지를 보낼 수 있다. 이 스크립 트로는 Patch 를 중 단시킬 수 
없다. 

기타훅 

pre-rebase 흑은 Rebase 하기 전에 실행 된다. 이 흑이 0 이 아닌 값을 반 환하면 Rebase 가추 | 소 된다. 이 

흑으로 이미 Push 한 커밋을 Rebase 하지 못하게 할 수 있다. Git 이 자 동으로 넣 어주는 pre-rebase 예제 
가바 로그예 제다. 이 예 제에는 기준브 탠치가 next 라고돼 있다. 실제로 격용할 브랜치 이름으 로사용 
하면 된다. 

그리고 git checkout 명렁이 끝나면 post-checkout 흑이 실행 된다. 이 흑은 Checkout 할 때마다 작업 

하는 디텍토 리에서 뭔가 할 일이 있을 때 사용 한다. 그 러니까 용량이 크거나 Git 이 관 리하지 않는 파일 
을 옮기 거나, 문서를 자 동으로 생 성하는 데 쓴다. 

마지막 으로, post-merge 흑은 Merge 가 끝나고 나서 실행 된다. 이 흑 은파일 권한 같이 Git 이 추 적하지 

않는 정보를 관 리하는 데 사용 한다. Merge 로 Working Tree 가 변경될 때 Git 이 관 리하지 않는 파일이 
원하는 대로 잘 배치 됐는지 검사할 때도 좋다. 

7.3.3 서버흑 

클라 이언트 흑 으로도 어떤 정책을 강제할 수 있 지만， 시스렘 관리자 에게는 서 버흑이 더 중요 하다. 서 
버 흑은 모두 Push 전후에 실행 된다. Push 전에 실 행되는 흑이 0 이 아닌 값을 반 환하면 해당 Push 는 
거 질되고 클라이 언트는 에러 메 시지를 출력 한다. 이 흑으로 아주 복잡한 Push 정책도 가능 하다. 

pre— receive 외" post- receive 

Push 하면 가장 처음 실 행되는 흑은 pre— receive 흑 이다. 이 스크 립트는 표준 입력 (ST 이 N) 으로 
Push 하는 레퍼 런스의 목록을 입력받 는다. 0 이 아닌 값을 반 환하면 해당 레퍼 런스가 전부 거결 된다. 
Fast-forward Push 가 아니면 거절하 거나， 브랜치 Push 권한을 제어 하려면 이 흑에서 하는 것이 좋 
다. 관 리자만 브 탠치를 새로 Push 하고 삭제할 수 있고 일반 개 발자는 수정 사항만 Push 할 수 있게 할 
수 있다. 



191 



7 장 Git 맞춤 



Scott Chacon Pro Git 



post-receive 흑은 Push 한후에 실행 된다. 이 흑으 로사용 자나서 비스에 알림 메시지 를보널 수 있다. 
그리고 pre-receive 흑처럼 표준 입력 (ST 이 N) 으로 레 퍼런스 목록이 넘어 간다. 이 흑으로 메일 링리스 

트에 메일 을보내 거나， CI (Continuous Integration) 서버나 Ticket-tracking 시 스템의 정보 를수정 
할 수 있다. 심지어 커밋 메 시지도 파싱할 수 있기 때문에 이 흑으로 Ticket 을 만 들고, 수정 하고, 닫을 
수 있다. 이 스크 립트가 완견히 종료할 때까지 클 라이언 트와의 연결은 유 지되고 Push 를 중 단시킬 수 
없다. 그래서 이 스크 립트로 시간이 오래 걸 릴만한 일을 할 때는 조 심해야 한다. 



update 스크 립트는 각 브랜 치마다 한 번씩 실행 된다는 것을 제 외하면 pre-receive 스크 립트와 거의 같 
다. 한 번에 브랜치 를여러 개 Push 하면 pre-receive 는 딱 한 번만 실행되 지만, update 는 브탠 치마다 
실행 된다. 이스크 립트는 표준입 력으로 데이터 를입력 받는것 이아니 라아규 먼트로 브탠치 이름， 원래 
가 리키던 SHA-1 값， 사 용자가 Push 하는 SHA-1 값을 입력받 는다. update 스크 립트가 0 이 아닌 값 
을 반 환하면 해당 레퍼 런스만 거 결되고 나머지 다른 레퍼 런스는 상관 없다. 



7.4 정책구 현하기 

지 금까지 배운 것을한 번 적용해 보자. 커밋 메시지 규칙 검사 하고, Fast-forward Push 만허용 하고， 
디롁토 리마다 사 용자의 수정 권한을 제 어하는 Workflow 를 만 든다. 실질 격으로 정책을 강제 하려면 서 
버 흑으로 만 들어야 한다. 하 지만， 개발 자들이 Push 할 수 없는 커밋은 아예 만들지 않도록 클라 이언트 
흑도 만 든다. 

필자가 제일 좋 아하는 Ruby 로 만 든다. 필자는 독자가 슈도 코드를 읽듯이 Ruby 코드를 읽을 수 있다 
고 생각 한다. Ruby 를 모르 더라도 충분히 개념을 이해할 수 있을 것 이다. 하지 만， Git 은 언어를 가리지 
않 는다. Git 이 자 동으로 생성 해주는 예제는 모두 Perl 과 Bash 로 작성돼 있다. 그래서 예제를 열어 보면 
Perl 과 Bash 로 작성된 예제를 참고 할 수 있다. 

7.4.1 서버흑 

서버 정책은 견부 update 흑으로 만 든다. 이 스크 립트는 브 랜치가 Push 될 때마다 한 번 실 행되고 해 
당브 탠치의 이름, 원래 브랜 치가가 리키던 레퍼 런스, 새 레 퍼런스 를아규 먼트로 받 는다. 그리고 SSH 를 
통해서 Push 하는 것 이라면 누가 Push 하는 지도 알 수 있다. SSH 로 집 근하긴 하지만 개발자 모두 계정 
하나로 ("git" 같은) Push 하고 있다면 실제로 Push 하는 사람이 누 구인지 판별해 주는쉘 Wrapper 가 
필요 하다. 이 스 크립트 에서는 $user 환경 변수에 현재 집속 한사용 자정보 가있다 고가정 한다. update 
스크 립트는 필요한 정보를 수 집하는 것으로 시작 한다: 



#! /usr/bin/env ruby 

refname = ARGV[0] 
oldrev = ARGV[1] 
newrev = ARGV[2] 
user = ENV[ 'USER' ] 

puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6] }) (#{newrev[0,6]}) 



update 
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커밋 메시지 규칙 만들기 

커밋 메시지 규 칙부터 해 보자. 일 단목표 가있어 야하니 까커밋 메 시지에 "ref: 1234" 같은스 트링이 
포함돼 있어 야한다 고가정 하자. 보통 커밋은 이슈트 래커에 있는 이슈와 관련돼 있으니 그이슈 가뭔지 
커밋 메 시지에 적어 놓으면 좋다. Push 할 때마다 커밋 메 시지에 해당 스 트링이 포함돼 있는지 확인한 
다. 만약 커밋 메 시지에 해당 스 트링이 없는 커 밋이면 0 이 아닌 값을 반 환해서 Push 를 거질 한다. 

$newrev, $oldrev 변수와 git rev-list 라는 Plumbing 명 렁어를 이 용해서 Push 하는 커밋의 모든 
SHA-1 값 을알수 있다. 이것은 git log 와근 본적으 로같은 명렁이 고옵션 을하나 도주지 않으면 다른 
정 보없이 SHA-1 값 만보여 준다. 이 명 렁으로 Push 하는커 밋을모 두알수 있다: 



$ git rev-list 538c33 . . d14f c7 
d14fc7c847ab946ec39590d87783c69b031 bdfb7 
9f585da4401 b0a3999e841 1 3824d1 5245c 13f0be 
234071 a 1 be950e2a8d078e6141 f5cd20de61 ad3 
dfa04c9ef3d51 97182f1 3fb5b9b1 fb771 7d2222a 
1 771 6ec0f1 ff5c77eff40b7fe91 2f9f6cfd0e475 



이 SHA-1 값 으로각 커밋의 메시지 도가져 온다. 커밋 메시 지를가 겨와서 정규 표현식 으로해 당패턴 
이 있는지 검사 한다. 

커밋 메시 지를얻 는방법 을알아 보자. 커밋의 raw 데 이터는 git cat-file 이라는 Plumbing 명 렁어로 
얻을수 있다. 9 장에서 Plumbing 명 렁어에 대해 자세히 다루니 까지금 은커밋 메시지 얻 는것에 집중 
하자: 

$ git cat-file commit ca82a6 

tree cfda3bf379e4f8dba871 7dee55aab78aef7f4daf 

parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 

author Scott Chacon <schacon@gmail.com> 1205815931 -0700 

committer Scott Chacon 〈schacon@gmail.com〉 1240030591 -0700 



changed the version number 




이 명렁이 출력하 는메시 지에서 커밋 메시 지만잘 라내야 한다. 첫 번째 빈즐다 음부터 가커밋 메시지 
니까 유닉스 명렁어 sed 로 첫빈즐 이후를 잘라 낸다. 



$ git cat-file commit ca82a6 | sed '1,/ A $/d 
changed the version number 




이제 커밋 메시 지에서 찾는 패턴과 일 치하는 문 자열이 있는지 검 사해서 있으면 통과 시키고 없으면 거 

결 한다. 스크립 트가종 료할때 0 이 아닌 값을반 환하면 Push 가거결 된다. 이 일 을하는 코드는 아래와 
같다: 
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$regex = ALref. (\d+)\J/ 




# enforced custom commit message format 




def check_message_format 




missed— revs = 、git rev-list #{$oldrev}. .#{$newrev}、 .split("\n") 




missed— revs . each do I rev I 




message = git cat— file commit #{rev} ！ sed 1 1 , / A $/d 1 




if ！ $regex . match( message) 




puts " [POLICY] Yo 니 r message is not formatted correctly" 




exit 1 




end 




end 




end 




check— message— format 







이 코드를 update 스크 립트에 넣으면 규칙을 어긴 커밋은 Push 할 수 없다. 



ACL 로 사용 자마다 다른 규칙 적 용하기 

진 행하는 프로 젝트에 모들이 여러 개 있 는데， 모 들마다 속한 사용 자들만 Push 할 수 있게 설 정해야 한 
다고 가정 하자. 모든 권한을 다 가진 사 람들도 있고 특정 디텍 토리나 파일만 Push 할 수 있는 사람도 있 
다. 이런 일을 강제 하려면 먼저 서버의 Bare 저 장소에 aci 이라는 파일을 만들고 거기에 규칙을 기술한 
다. 그리고 update 흑에서 Push 하는 파일이 무 엇인지 확 인하고 ACL 과 비 교해서 Push 할 수 있는지 
없는지 결정 한다. 

우선 ACL 부터 작성 한다. CVS 에서 사 용하는 것과 비숫한 ACL 을 만 든다. 규칙은 한 줄에 하나씩 기술 
한다. 각 줄의 첫 번째 필드는 avail 이나 unavail 이고 두 번째 필드는 규칙을 적용할 사용 자들의 목록을 

CSV (Comma-Separated Values) 형 식으로 격 는다. 마지막 필드엔 규칙을 적용할 경로를 적 는다. 
만약 마지막 필드가 비워져 있 으면모 든경로 를의미 한다. 이 필드는 파이프 (|) 문자 로구분 한다. 
관리자 도여러 명 이고, doc 디텍토 리에서 문서 를만드 는사람 도여러 명 이다. 하지만 lib 고 hests 디텍 
토리에 접 근하는 사람은 한명 이다. 이런 상황을 ACL 로 만들면 아래와 같다: 

avail ！ nickh,pjhyettjdefunkt/tpw 
avail ！ usinclair ᅭ dickens, brcinte I doc 
avail ！ schacon ！ lib 
avail ！ schacon ！ tests 



이 ACL 정보는 스크립 트에서 읽어 사용 한다. 설명을 쉽게 하고자 여 기서는 avail 만 처리 한다. 다음 메 
소드는 Associative Array 를 반환하 는데, 키는 사 용자이 름이고 값은 사 용자가 Push 할 수 있는 경로 
의 목록이 다: 



def get— acl— access— data(acl— file) 
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# read in ACL data 




acl— file = File.read(acl_file) .split ( "\n" ) .reject { ！ line! line = ' 


' } 


access = {} 




acl_file.each do ！ line! 




avail, users, path = line. split( 1 ! 1 ) 




next unless avail == 'avail 1 




users. split( 1 , 1 ) .each do luser! 




access[user] ！! = [ ] 




access[user] « path 




end 




end 




access 




end 




이 함수가 ACL 파일을 처 리하고 나서 반 환하는 결과는 아래와 같다: 


{"defunkt"=>[nil] / 




■—I 








I ~ 1 

효 




"schacon"=>[ "lib" , "tests" ] , 




"cdickens"=>[ "doc" ] , 




"usinclair ,l= >[ "doc" ] , 




"ebronte"=>[ "doc" ] } 





바로 사용할 수 있는 권한 정보를 만들 었다. 이제 Push 하는 파일을 그 사 용자가 Push 할 수 있는지 없 
는지알 아내야 한다. 

git log 명렁에 -name-only 옵션을 주면 해당 커 밋에서 수정된 파일이 뭔지 알려 준다. git log 명렁은 
2 장에서 다루 었다: 

$ git log -1 —name-only ―— pretty=format: ' 1 9f585d 

README 
lib/test. rb 



get_acl_access_data 메 소드를 호 출해서 ACL 정보를 구 하고， 각 커밋에 들어 있는 파일 목록도 얻은 다 

음에， 사 용차가 모든 커밋을 Push 할 수 있는지 판단 한다: 

# only allows certain users to modify certain subdirectories in a project 
def check_directory_perms 
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access = get— acl— access— data ( 'acl' ) 

# see if anyone is trying to push something they can't 
new_commits = "git rev-list #{$oldrev}. .#{$newrev}、 .split("\n") 
new_commits.each do |rev| 
files—modified = "git log —1 ―— name-only ―— pretty=f ormat ： 1 1 #{rev}\splii:(''\rr) 
f iles_modif ied . each do | path I 
next if path. size = 0 
has_file— access = false 
access[$user] .each do |access_path| 
if ！ access_path ！ ] # user has access to everything 
(path. index(access_path) = 0) # access to this path 
has_file— access = true 
end 
end 

if ！ has_file_access 
puts " [POLICY] You do not have access to push to #{path}" 
exit 1 
end 
end 
end 
end 



check_directory_perms 




어렵지 않다. 먼저 git rev-list 명 렁으로 서버에 Push 하려는 커밋이 무 엇인지 알아 낸다. 그 리고각 
커 밋에서 수정한 파일이 어떤 것들이 있는지 찾고， 해당 사 용자가 모든 파일에 대한 권한이 있는지 확인 
한다. Rubyism 철학에 따르면 path. inde X ( aC cess— path) = 0 이란 표현은 불명확 하다. 이 표현 은해당 
파일의 경로가 access—path 로 시작할 때 참 이라는 뜻 이다. 그 러니까 access— path 가 단순히 허용된 파일 
하나를 의 미하는 것이 아니라 access— path 로 시 작하는 모든 파일을 의미 한다. 

이제 사 용차는 메시지 규칙을 어 겼거나 권한이 없는 파일이 포함된 커밋 은어떤 것도 Push 하지 못한 
다, 

Fast-Forward Push 만허 용하기 

이제 Fast— forward Push 가아니 면거절 되게해 보자. receive. denyDeletes 오 Receive. denyNonFastForwards 
설 정으로 간 단하게 거절할 수 있다. 하 지만， 그이전 버 견에는 꼭 흑으로 구 현해야 했다. 게다가 특정 사 
용자만 제한 하거나 허용 하려면 흑으로 구 현해야 한다. 

기존에 있던 커밋이 Push 하는브 탠치에 없으면 Fast-forward Push 가아 니라 고판단 한다. 커밋하 
나라도 없으면 거 걸하고 모두 있으면 Fast-forward Push 이으로 그대로 둔다: 

# enforces fast-forward only pushes 
def check_fast— forward 
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missed— refs = N git rev-list #{$newrev} . .#{$oldrev}、 
missed_ref_count = missed_ref s. split ( "\n" ) .size 
if missed— ref— count > 0 

puts " [POLICY] Cannot push a non fast-forward reference" 

exit 1 
end 
end 

check_fast— forward 

이정책 을다구 현해서 update 스크 립트에 넣고 chmod u+x .git/hooks/update 명렁으 로실행 권한을 

준다. 그리고 나서 -f 옵선을 주고 강제로 Push 하면 아래와 같이 실페 한다: 

$ git push — f origin master 

Counting objects: 5, done. 

Compressing objects: 100% (3/3), done. 

Writing objects: 100% (3/3), 323 bytes, done. 

Total 3 (delta 1), reused 0 (delta 0) 

Unpacking objects: 100% (3/3), done. 

Enforcing Policies. . . 

(refs/heads/master) (8338c5) (c5b616) 

[POLICY] Cannot push a non-fast-forward reference 

error: hooks/update exited with error code 1 

error: hook declined to update refs/heads/master 

To git@gitserver: project .git 

！ [remote rejected] master -> master (hook declined) 
error: failed to push some refs to 1 git@gitserver: project . git 1 



정책과 관련해 하나씩 살펴 보자. 먼저 흑이 실행될 때마다 다음 메시지 가출력 된다. 

Enforcing Policies. . . 
(refs/heads/master) (fb8c72) (c 56860) 

이것은 update 스 크립트 맨 윗부 분에서 표 준출력 (STDOUT) 에 출력한 내용 이다. 스크립 트에서 표준 
출 력으로 출 력하면 클라이 언트로 전송 된다. 이점을 꼭기억 하자. 
그리고 아래의 에러메 시지를 보자: 

[POLICY] Cannot push a non fast-forward reference 
error: hooks/update exited with error code 1 
error: hook declined to update refs/heads/master 
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첫 번째 줄은 스크립 트에서 직접 출력한 것이고 나머지 두 줄은 Git 이 출력해 주는 것 이다. 이 메 시지는 
update 스크립 트에서 0 이 아닌 값을 반 환해서 Push 할 수 없다는 메시 지다. 그리고 마지막 메 시지를 
보자: 



To git@gitserver: project .git 

！ [remote rejected] master -> master (hook declined) 
error: failed to push some ref s to 1 git@gitserver ： proj ect . git 



이 메 시지는 흑에서 거질된 것 이라고 말해 주는것 이고브 탠치가 거부될 때마다 하나씩 출력 된다. 

게다가 Push 하는 커밋에 커밋 메시지 규칙을 지키지 않은 것이 하 나라도 있으면 아래와 같은 에러 메 
시지 를보여 준다: 



[POLICY] Your message is not formatted correctly 




그리고 누군가 권한이 없는파 일을수 정해서 Push 해 도에러 메시지 를출력 한다. 예 를들어 문서 담당 
자가 lib 디텍 토리에 있는 파일을 수 정해서 커 밋하면 아래와 같은 메 시지가 출력 된다: 



[POLICY] You do not have access to push to lib/test. rb 



이제 서버 흑은 다 만들 었다. 앞 으로는 update 스크 립트가 항상 실행될 것이기 때문에 저 장소를 되돌 
릴 수 없고, 커밋 메 시지도 규 칙대로 작 성해야 하고, 권한이 있는 파일만 Push 할 수 있다. 

7.4.2 클라이 언트흑 

서버 흑의 단점은 Push 할 때까지 Push 할 수 있는지 없는지 알 수 없 다는데 있다. 기껏 공들여 정성껏 
구현 했는데 막상 Push 할 수 없으면 곤흑스 립다. 히스 토리를 제대로 고치는 일은 정신 건강에 매우 해롭 
다. 

이 문 제는클 라이언 트흑으 로해결 한다. 클라이 언트흑 으로서 버가거 부할지 말지 검사 한다. 사 람들은 
커 밋하기 견에， 그 러니까 시간이 지나 고치기 어려 워지기 견에 문 제를해 결할수 있다. Clone 할때 이 

흑은견 송되지 않기 때문에 다 른방법 으로동 료에게 배 포해야 한다. 그흑을 가져다 .git/hooks 디텍토 

리에 복 사하고 실행할 수 있게 만 든다. 이 흑 파일을 프로 젝트에 넣어서 배 포해도 되고 Git 흑 프 로젝트 
를 만 들어서 배 포해도 된다. 하 지만， 자 동으로 설 치하는 방법은 없다. 

커밋 메시 지부터 검사해 보자. 이 흑이 있으면 커밋 메시 지가구 리다고 서버가 뒤늦게 거 결하지 않 는다. 

이것은 comit-msg 흑으로 구현 한다. 이 흑은 커밋 메 시지가 저장된 파일을 첫 번째 아규 먼트로 입력받 

는다. 그 파일을 읽어 패턴을 검사 한다. 필요한 패턴이 없으면 커밋을 중단시 킨다: 

#! /usr/bin/env ruby 

message— file = ARGV[0] 

message = File. read (message_file) 
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$regex = A[ref: (\d+)\]/ 

if ！ $regex . match (message) 

puts " [POLICY] Your message is not formatted correctly 

exit 1 
end 



이 스크 립트를 .git/hooks/commit-msg 라 는파일 로만들 고실행 권한을 준다. 커밋이 메시지 규 칙을어 
기 면아래 와같은 메시지 를보여 준다: 



$ git commit —am 'test' 

[POLICY] Your message is not formatted correctly 




커 밋하지 못 했다. 하 지만, 커밋 메 지시를 바르게 작 성하면 커밋할 수 있다: 

$ git commit —am 'test [ref: 132] 1 
[master e05c914] test [ref: 132] 
1 files changed, 1 insertions(+) , 0 deletions(-) 



그리고 아예 권한이 없는 파일을 수정 못하게 할 때는 pre—commit 흑을 이용 한다. 사전에 .git 디 렉토리 
안에 ACL 파 일을가 겨다놓 고아래 와같이 작성 한다: 

#! /usr/bin/env ruby 
$user = ENV['USER'] 

# [ insert acl_access_data method from above ] 

# only allows certain users to modify certain subdirectories in a project 
def check_directory_perms 

access = get_acl_access_data( 1 .git/acl 1 ) 

files— modified = "git diff— index —cached —name-only HEAD" .split("\n") 
f iles_modified.each do jpath ！ 

next if path. size == 0 

has_file_access = false 

access[$user] .each do |access_path| 

if ！ access— path ！ ！ (path.index(access_path) ==0) 
has_file— access = true 

end 
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if ！ has— file— access 
puts " [POLICY] You do not have access to push to #{path} 
exit 1 
end 
end 
end 

check_directory_perms 



내용은 서버 흑과 똑 같지만 두 가지가 다 르다. 첫째, 클라 이언트 흑은 Git 디텍 토리가 아니라 워킹 디텍 
토 리에서 실 행하기 때문에 ACL 파일 위치가 다 르다. 그래서 ACL 파일 경 로를수 정해야 한다: 



access = get_acl_access_data( 'acl' ) 



이부분 을아래 와같이 꾼다: 



access = get_acl_access_data( 1 .git/acl' ) 



두 번째 차 이점은 파일 목록을 얻는 방법 이다. 서버 흑 에서는 커밋에 있는 파일을 모두 찾 았지만 여기 

서는 아직 커밋 하지도 않 았다. 그래서 Staging Area 의 파일 목록을 이용 한다: 



files— modified = "git log —1 ―— name-only — pretty=format: 1 ' #{ref} 




이부분 을아래 와같이 꾼다: 



files— modified = "git diff— index ―— cached ―— name-only HEAD" 

이 두가지 점만 다르고 나 머지는 똑 같다. 보통은 리모트 저 장소의 게정과 로컬의 계정도 같다. 다른 계 
정 을사용 하려면 $ user 환경 변수에 누군지 알려야 한다. 

Fast-forward Push 인지 확 인하는 일이 남 았다. 보통은 Fast-forward 가 아닌 Push 는 좀 드 물다. 
Fast—forward 가아닌 Push 를 하려면 Rebase 로이미 Push 한커밋 을바꿔 버렀거 나전혀 다 른로걸 
브 탠치를 Push 하는 경 우다. 

어 쨌든이 서버는 Fast-forward Push 만허 용하기 때문에 이미 Push 한커밋 을수정 했다면 그건 아마 
실수로 그랬을 것 이다. 이 실수를 막는 흑을 살펴 보자. 

아래는 이미 Push 한 커밋을 Rebase 하지 못하게 하는 pre-rebase 스크립 트다. 이 스크 립트는 먼저 
Rebase 할 커밋 목록을 구하고 커밋이 리모트 레 퍼런스 / 브 탠치에 들어 있는지 확인 한다. 커밋이 한 개 
라도 리모트 레 퍼런스 / 브 탠치에 들어 있으면 Rebase 할수 없다: 
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#! /usr/bin/env ruby 




base_branch = ARGV[0] 




if ARGV[1] 




topic— branch = ARGV[1 ] 




else 




topic— branch = "HEAD" 




end 




target_shas = v git rev-list #{base_branch}. .#{topic_branch}' 


\split("\n") 


remote_refs = v git branch -r" . split("\n" ) .map { !r ! r. strip 


} 


target_shas.each do ！ sha ！ 




remote_refs.each do ！ remote_ref ！ 




shas— pushed = "git rev-list A #{sha} A @ refs/remoi:es/#{ren 


iote_ref }、 


if shas— pushed . split( "\n" ) . include?(sha) 




puts " [POLICY] Commit #{sha} has already been pushed to #{remote_ref }'■ 


exit 1 




end 




end 




end 







이 스크 립트는 6 장 '리 비견 조호 | 하기' 결에서 설 명하지 않 은표현 을사용 했다. 아래의 표현은 이0 
Push 한커밋 목록을 얻어오 는부분 이다: 



git rev-list A #{sha} A ® refs/remotes/#{remote_ref } 



shaw 은 해당 커밋의 모든 부모를 가리 킨다. 그 러니까 이 명렁은 지금 Push 하려는 커 밋에서 리모트 저 
장소의 커밋에 도달할 수 있는지 확 인하는 명렁 이다. 즉， Fast-forward 인지 확 인하는 것 이다. 
이 방법은 매우 느리고 보통은 필요 없다. 어차피 Fast—forward 가 아닌 Push 은 — f 옵션을 주어야 
Push 할 수 있다. 문제가 될만한 Rebase 를 방지할 수 있다는 것을 보여 주려고 이 예제를 설명 했다. 

7.5 요약 

Git 을 프로 젝트에 맞추는 방법을 배 웠다. 주요한 서버 / 클라 이언트 설정 방법， 파일 단위로 설 정하는 
Git Attributes, 이벤트 흑, 정책을 강 제하는 방법을 배 웠다. 이제 필요한 Workflow 를 만들고 Git 을 
거기 에맞게 설 정할수 있을것 이다. 
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Git 으로 이전 하기 



Git 은완 벽하지 않다. 프 로젝트 를전부 Git 으 로옮기 기는어 렵다. 프 로젝트 가특정 VCS 시 스템에 매 
우 의존 격으로 개발 됐을 수도 있다. 보통은 Subversion 에 의존적 이다. 이번 장은 git svn 이라는 Git 
과 Subversion 을 양방 향으로 이어 주는 도구를 알아 보며 시작 한다. 

언젠가 이미 존 재하는 프 로젝트 환경을 Git 으로 변 경하고 싶게 될 것 이다. 이 장의 나머지 부 분에서 프 
로 젝트를 Git 으로 변 경하는 방법에 대해 다룰 것 이다. 먼저 Subversion 에서 프 로젝트 를옮겨 오는 방 
법을설 명하고 그 다 음에는 Perforce, 그리고 스크 립트를 직집 만 들어서 잘 쓰지 않는 VCS 에서도 프로 
젝트를 옮기는 방법을 다룰것 이다. 



8.1 Git 과 Subversion 

현재도 많은 오 픈소스 프로 젝트와 수 많은 기업 프로 젝트는 Subversion 으로 소스 코드를 관리 한다. 
1 0 여년간 Subversion 이 가장 인 기있는 오 픈소스 VCS 도구 였다. Subversion 은 그이견 시 대에서 가 
장 많이 사 용하던 CVS 와 많이 닮 았다. 

Git 이 자 랑하는 또 하나의 기능은 git svn 이라는 양방향 Subversion 지원 도구 이다. Git 을 Sub- 
version 클라이 언트로 사용할 수 있기 때문에 로컬 에서는 Git 의 기능을 활 용하고 Push 할 때는 
Subversion 서버에 Push 한다. 로컬 브 탠치와 Merge, Staging Area, Rebase, Cherry-pick 등의 
Git 기능을 충분히 사용할 수 있다. 같이 일하는 동료는 빛 한줄기 없는 선 사시대 동 굴에서 일하 겠지만 
말 이다. git svn 은기업 에서 git 을 사용할 수있도 록돕는 출발점 이다. 우리가 Git 을도 입하기 위해기 
업 내에서 노 력하는 동안 동료가 효을 적으로 환경을 바꿀 수 있도록 도움을 줄 수 잇다. Subversion 지 
원 도구는 우리를 DVCS 세 상으로 인 도하는 붉은 알약과 같은 것 이다. 

8.1.1 git svn 

Git 과 Subversion 을이 어주는 명령은 git svn 으 로시작 한다. 이 명렁 뒤에추 가하는 명렁이 몇가지 
더 있으며 간단한 예제를 보여주 고설명 한다. 

git svn 명 령을사 용할때 는절름 발이인 Subversion 을사용 하고있 다는점 을염두 하자. 우리 가로컬 
브 랜치와 Merge 를 맘대로 쓸 수 있다고 하 더라도 최대한 일직 선으로 히스 토리를 유지하 는것이 좋다. 
Git 저 장소처 럼사용 하지않 는다. 

히 스토리 를재작 성해서 Push 하지 말아야 한다. Git 을 사용하 는동료 들끼리 따로 Git 저 장소에 Push 
하지도 말아야 한다. Subversion 은 단 순하게 일직선 히스 토리만 가능 하다. 팀원중 일부는 SVN 을 사 
용하고 일부는 Git 을사용 하는팀 이라면 SVN Server 를사 용해서 협업하 는것이 좋다. 그래 야삶이 편 
해 진다. 
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8.1.2 설 정하기 

git svn 을사용 하려면 SVN 저장 소가하 나필요 하다. 저 장소에 쓰기 권한이 있어야 한다. 필자의 test 
저 장소를 복사 한다. Subversion(1 .4 이상) 에 포함된 svnsync 라는 도구를 사 용하여 SVN 저 장소를 
복사 한다. 테 스트용 겨 장소가 필 요해서 Google Code 에 새로 Subversion 저 장소를 하나 만들 었다. 

protobuf 라는 프로 젝트의 일부 코드를 복사 했다. protobuf 는 네 트워크 전송에 필요한 구 조화된 데이터 
(프 로토콜 같은 것들) 의 인 코딩을 도 와주는 도구 이다. 

로걸 Subversion 저 장소를 하나 만 든다: 



$ mkdir /tmp/test-svn 

$ svnadmin create /tmp/test-svn 




그리고 모든 사 용자가 revprops 속성을 변경할 수 있도록 항상 0 을 반 환하는 pre-revprop-change 
스크립 트를준 비한다 (역주 ： 파일이 없 거나, 다른 이름으 로되어 있을수 있다. 이 경 우아래 내용 으로새 
로 파일을 만들고 실행 권한을 준다) ： 

$ cat /tmp/test-svn/hooks/pre-revprop-change 

#!/bin/sh 

exit 0； 

$ chmod +x /tmp/test-svn/hooks/pre-revprop-change 



이제 svnsync init 명 렁으로 다른 Subversion 저 장소를 로컬로 복사할 수 있도록 지정 한다: 
$ svnsync init file: ///tmp/test-svn http ： // progit-example . googlecode . com/ svn/ 



이렇게 다른 겨 장소의 주소를 설 정하면 복사할 준비가 된다. 아래 명 령으로 저 장소를 실제로 복사 한다: 



$ svnsync sync file: ///tmp/test-svn 

Committed revision 1 . 

Copied properties for revision 1 . 

Committed revision 2. 

Copied properties for revision 2. 

Committed revision 3. 



이 명렁 은몇분 걸리지 않 는다. 저 장하는 위치가 로컬이 아 니라리 모트서 버라면 오래 걸 린다. 커밋이 

100 개 이하 라고해 도오래 걸 린다. Subversion 은 한번에 커밋을 하나씩 받아서 Push 하기 때문에 엄 
청나게 비효 율적이 다. 하지 만, 겨장 소를복 사하는 다른 방법은 없다. 
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8.1.3 시 작하기 

이제 갖고늘 Subversion 저장 소를하 나준비 했다. git svn clone 명 렁으로 Subversion 저장 소견체 
를 Git 저장소 로가져 온다. 만약 Subversion 저 장소가 로컬에 있 는것이 아니라 리모트 서버에 있으면 

file:///tmp/test-svn 부분에 서버 저 장소의 URL 을격어 준다. 



$ git svn clone f ile:///tmp/test-svn — T trunk — b branches -t tags 

Initialized empty Git repository in /Users/schacon/projects/testsvnsync/svn/.git/ 

r1 = b4e387bc68740b5af56c2a5faf4003ae42bd135c (trunk) 

A m4/acx_pthread . m4 

A m4/stl_hash.m4 

r75 = d 1 957f 3b3079221 24eec631 4e1 5bcda59e3d961 0 (trunk) 
Found possible branch point: f ile:///tmp/test-svn/trunk => \ 

f ile:///tmp/test-svn /branches/my-calc-branch, 75 
Found branch parent: (my-calc— branch) d1 957f 3b3079221 24eec631 4e1 5bcda59e3d961 0 
Following parent with do_switch 
Successfully followed parent 

r76 = 8624824ecc0badd73f 40ea2f 01 f ce51 8941 89b01 (my— calc— branch) 
Checked out HEAD: 

f ile:///tmp/test-svn/branches/my-calc-branch r76 




이명렁 은사실 SVN 저장 소주소 를주고 git svn init 고ᅡ git svn fetch 명렁을 순서대 로실행 한것과 
같다. 이 명렁은 시간이 좀 걸 린다. 테스트 용프로 잭트는 커밋이 75 개 정도 밖에 안되서 시간이 많이 걸 
리지 않 는다. Git 은 커밋을 한번에 하나썩 일일이 기 록해야 한다. 커밋이 수 천개인 프로 젝트라 면몇시 
간 흑은몇 일이걸 릴수도 있다. 

-t trunk — b branches -t tags 부분은 Subversion 이어떤 브탠치 구조를 가지고 있는지 Git 에 게알려 
주는 부분 이다. Subversion 표준 형식과 다르면 이 웁션 부 분에서 알맞은 이름을 지정해 준다. 표준 형 
식 을사용 한다면 간 단하게 -s 옵션 을사용 한다. 즉 아래의 명 렁도같 은의미 이다. 



$ git svn clone file ： /// tmp/test-svn — s 



Git 에서 브 탠치와 태그 정보가 제대로 보이는 것을 확인 한다: 



$ git branch -a 

* master 
my-calc-branch 
tags/2.0.2 
tags/release— 2.0. 1 
tags/release— 2.0.2 
tags/ release— 2 . 0 . 2rc1 
trunk 
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git svn 도구가 리모트 브 탠치의 이름을 어떻게 칫는지 알아야 한다. Git 저 장소를 Clone 할 때는 보통 
origin/branch] 처럼 리모트 저장소 이름이 들어간 브탠치 이 름으로 만들어 진다. git svn 은우 리가리 
모트 저 장소를 딱 하나만 사용 한다고 가정 한다. 그래서 리모트 저 장소의 이름을 붙여서 브 탠치를 관리 

하지 않 는다. Plumbing 명 렁어인 show-ref 명 렁으로 리모트 브 탠치의 정확한 이 름을확 인할수 있다. 

$ git show— ref 

1 Cbd4904d9982f386d87f88fce1 c24ad7c0f0471 ref s/heads/master 

aeel ecc2631 81 64f 355a883f 5d99cf f 0c852d3c4 ref s/remotes/my-calc-branch 

03d09b0e2aad427e34a6d50ff1 471 28e76c0e0f5 refs/remotes/tags/2 .0.2 

50d02cc0adc9da431 9eeba0900430ba21 9b9c376 ref s/remotes/tags/release-2 .0.1 

4caaa71 1 a50c77879a91 b8b90380060f672745cb ref s/remotes/tags/release-2 .0.2 

1 c4cb5G81 44c51 3ff1 21 4c3488abe66dcb9291 6f ref s/remotes/tags/release-2 . 0 . 2rc1 

1 Cbd4904d9982f386d87f88fce1 c24ad7c0f 0471 ref s/remotes/trunk 



일 반격인 Git 저장 소라면 아래 와비숫 하다: 

$ git show— ref 

83e38c7a0af 325a9722f 2f dc56b1 01 88806d83a1 ref s/heads/master 
3e1 5e38c1 98baac84223acfc6224bb8b99ff2281 ref s/remotes/gitserver/master 
Oa30dd3b0c795b80212ae723640d4e5d48cabdff refs/remotes/origin/master 
2581 2380387fdd55f91 6652be4881 c6f1 1 600d6f ref s/remotes/origin/testing 

이 결과를 보면 리모트 저 장소가 두 개 있다. gitserver 라는 리모트 저 장소에 master 브 랜치가 있고 
origin 이라는 리모트 저 장소에 master, testing 브 랜치가 있다. 

git svn 으로 저 장소를 가 겨오면 Subversion 태그는 Git 태그가 아니라 리모트 브 랜치로 등 록되는 점 
을 잘기억 하자. git svn 은 Subversion 태그를 tags 라는 리모트 서버에 있 는브탠 치처럼 만 든다. 

8.1.4 Subversion 서버에 커 밋하기 

자 작업할 Git 저장소 는준비 했다. 무 엇인가 수정하 고서버 로고친 내용을 Push 해야 할때가 왔다. Git 
을 Subversion 의 클라이 언트로 사 용해서 수정한 내용을 견송 한다. 어떤 파일을 수 정하고 커밋을 하면 
그 수정한 내용은 Git 의 로컬 저 장소에 저장 된다. Subversion 서 버에는 아직 반 영되지 않 는다. 

$ git commit —am 'Adding git— svn instructions to the README' 
[master 97031e5] Adding git— svn instructions to the README 
1 files changed, 1 insertions(+) , 1 deletions(-) 



이제 수정한 내용을 서버로 전송 한다. Git 저 장소에 여 러개의 커밋을 쌓 아놓고 한번에 Subversion 서 

버로 보낸다 는점을 잘살펴 보자. git svn dc 에 imit 명 령으로 서버에 Push 한다. 
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$ git svn dcommit 

Committing to file:///tmp/test— svn/trunk ... 

M README.txt 
Committed r79 

M README.txt 
r79 = 938b1a547c2cc92033b74d32030e86468294a5c8 (trunk) 
No changes between current HEAD and refs/remotes/trunk 
Resetting to the latest refs/remotes/trunk 



이 명렁 은새로 추가한 커밋을 모두 Subversion 에 커밋하 고로컬 Git 커밋을 다시 만 든다. 커밋을 다시 
만들기 때문에 이미 저장된 커밋의 SHA-1 체 크심이 바 뀐다. 그래서 리모트 Git 거 장소와 Subversion 
저 장소를 함께 사 용하면 안 된다. 새로 만 들어진 커밋을 살 펴보면 아래와 같이 git-svn-id 가추가 된다: 

$ git log -1 

commit 938b1 a547c2cc92033b74d32030e86468294a5c8 

Author: schacon <schacon@4c93b258-373f-1 1de-be05-5f7a86268029> 

Date: Sat May 2 22:06:44 2009 +0000 

Adding git— svn instructions to the README 

git-svn-id ： file ： ///tmp/test-svn/trunk@79 4c93b258-373f-1 1 de-be05-5f7a86268G29 



원래 9703ie5 로시 작하는 SHA 체 크심이 지금은 938bia5 로시작 한다. 만약 Git 서버와 Subversion 서 
버에 함께 Push 하고 싶으면 우선 Subversion 서버에 dcommit 으로 Push 를 하고 그 다음에 Git 서버에 
Push 해야 한다ᅳ 

8.1.5 새로 운변경 사항받 아오기 

다른 개발자 와함께 일 하는과 정에서 다른개 발자가 Push 한상 태에서 Push 를하면 충돌이 날수 있다. 

충돌을 해 결하지 않으면 서버로 Push 할 수 없다. 충돌이 나면 git svn 명렁은 아래와 같이 보여 준다: 

$ git svn dcommit 

Committing to file:///tmp/test— svn/trunk 

Merge conflict during commit: Your file or directory 'README.txt' is probably \ 
out-of-date: resource out of date; try updating at /Users/schacon/libexec/git-\ 
core/git-svn line 482 



이 런상황 에서는 git svn rebase 명 렁으로 이문제 를해결 한다. 이명렁 은변경 사항을 서버에 서내려 
받고 그 다음에 로컬의 변경 사항을 그 위에 적용 한다: 
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$ git svn rebase 






M KbAUMb . IXt 






r80 = f f 829ab91 4e8775c7c025d741 beb3d523ee30bc4 (trunk) 






First, rewinding head to replay your work on top of it... 






Applying: first user change 






그러면 서버 코드 위에 변경 사항을 적 용하기 때문에 성공 격으로 


dcommit 명렁을 마칠수 있다: 




$ git svn dcommit 






Committing to f ile:///tmp/test-svn/trunk … 






M README.txt 






Committed r81 






M README.txt 






r81 = 456cbe6337abe491 54db701 06d1 836bc1 332deed (trunk) 






No changes between ajrrerrt HEAD and refs/remotes/tr 니 nk 






Resetting to the latest ref s/remotes/trunk 







Push 하기 전에 서버의 내용을 Merge 하는 Git 과달리 git svn 은 충돌이 날 때에만 서버에 업데 이트할 
것 이있다 고알려 준다. 이점 을꼭기 억해야 한다. 만약다 른사람 이한파 일을수 정하고 내가그 사람과 
다른 파일을 수정 한다면 dcommit 은 성공 격으로 수행 된다: 

$ git svn dcommit 

Committing to file:///tmp/test_svn/trunk 

M configure.ac 
Committed r84 

M autogen.sh 
r83 = 8aa54a74d452f 82eee1 0076ab2584c1 f c424853b (trunk) 

M configure.ac 
r84 = Cdbac939211ccb18aa744e581e46563af5d962d0 (trunk) 

W: d2f 23b80f 67aaaa1 f 6f 5aaef 48f ce3263ac71 a92 and refs/remotes/trunk differ, \ 
using rebase: 

： 100755 100755 efa5a59965fbbb5b2b0a12890f1b351bb5493c18 \ 
015e4c98c482f0fa71e4d5434338014530b37fa6 M autogen.sh 
First, rewinding head to replay your work on top of it. . . 
Nothing to do. 

Push 하고 나면 프로젝 트상태 가달라 진다는 점을기 억해야 한다. 충돌이 없으면 변경 사항이 바 램대로 
격 용되지 않아도 알 려주지 않 는다. 이 부분이 Git 과 다른 점이 다. Git 에서는 서버로 보내기 견에 프로젝 
트 상태를 견부 테 스트할 수 있다. SVN 은 서버로 커 밋하기 전과 후의 상태가 동일 하다는 것이 보장되 
지 않 는다. 
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git svn rebase 명령 으로도 Subversion 서버의 변경사 항을가 겨올수 있다. 커 밋을보 낼준비 가안됐 
어도^ 찮다. git svn fetch 명 령을사 용해도 되지만 git svn rebase 명령 은변경 사항을 가겨오 고적용 
까지 한 번에 해 준다. 

$ git svn rebase 

M generate— descriptor— proto . sh 
r82 = bd1 6df 91 73e424c6f 52c337ab6ef a7f 7643282f 1 (trunk) 
First, rewinding head to replay your work on top of it. . . 
Fast-forwarded master to refs/remotes/trunk. 



수시로 git svn rebase 명렁을 사용하 면로컬 코드를 항상최 신버견 으로유 지할수 있다. 이명 렁을사 
용하기 견에 워킹 디텍 토리를 깨 끗하게 만드는 것이 좋다. 깨 끗하지 못하면 Stash 를 하거나 임시로 커 

밋하고 나서 git svn rebase 명렁을 실 행하는 것이 좋다. 깨 끗하지 않으면 충돌이 나서 Rebase 가 중지 
될수 있다. 

8.1.6 Git 브탠 치문제 

Git 에 익숙한 사 람이면 일을 할 때 먼저 토픽 브 탠치를 만 들고， 일을 끝낸 다 음에， Merge 하는 방식을 
쓰려고 할 것 이다. 하 지만， git svn 으로 Subversion 서버에 Push 할 때에는 브 탠치를 Merge 하지 않 
고 Rebase 해야 한다. Subversion 은 일직선 히 스토리 밖에 모르고 Git 의 Merge 도 알지 못 한다. 그래 
서 git svn 은 첫 번쩨 부모 정 보만사 용해서 Git 커밋을 Subversion 커 밋으로 변경 한다. 
예 제를하 나살펴 보자. experiment 브탠치 를하나 만들고 2 개의 변 경사항 을커밋 한다. 그리고 master 

브 탠치로 Merge 하고 나서 dco^it 명 렁을수 행하면 아래 와같은 모양이 된다: 

$ git svn dcommit 

Committing to file://Atmp/test"svn/trunk ... 

M CHANGES.txt 
Committed r85 

M CHANGES.txt 
r85 = 4bfebeec434d156c36f2bcd18f4e3d97dc3269a2 (trunk) 
No changes between current HEAD and refs/remotes/trunk 
Resetting to the latest refs/remotes/trunk 
COPYING.txt： locally modified 
INSTALL.txt： locally modified 

M COPYING.txt 

M INSTALL.txt 
Committed r86 

M INSTALL.txt 

M COPYING.txt 
r86 = 2647f6b86ccfcaad4ec58c520e369ec81f7c283c (trunk) 
No changes between current HEAD and refs/remotes/trunk 
Resetting to the latest refs/remotes/trunk 
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Merge 커밋이 들어 있는 히스토 리에서 dcommit 명렁을 실행 한다. 그리고 나서 Git 히스 토리를 살펴보 

면 experiment 브 랜치의 커밋은 재작 성되지 않 았다. 대신 Merge 커밋만 SVN 서버로 전송 됐을뿐 이다. 

누 군가이 것을 내려 받으면 결과가 합처진 Merge 커밋 하나 만볼수 있다. 다른 사람은 언제 어디서 커 
밋 한것인 지알수 없다. 

8.1.7 Subversion 의 브탠치 

Subversion 의브 탠치는 Git 의브 탠치와 달라서 가능 한사용 을하지 않 는것이 좋다. 하지만 git svn 으 
로도 Subversion 브 탠치를 관리할 수 있다. 

SVN 브랜치 만들기 

Subversion 브탠 치를만 들려면 git svn branch [branchname] 명렁 을사용 한다: 
$ git svn branch opera 

Copying file:///tmp/test-svn/trunk at r87 to file:///tmp/test-svn/branches/opera. . . 
Found possible branch point: f ile:///tmp/test-svn/trunk => \ 

f ile:///tmp/test-svn/branches/opera, 87 
Found branch parent: (opera) 1 f 6bf e471 083cbca06ac8d41 76f 7ad4de0d62e5f 
Following parent with do— switch 
Successfully followed parent 

r89 = 9b6f e0b90c5c9adf 91 65f 70089751 8dbc54a7cbf (opera) 



이 명령은 Subversion 의 svn copy trunk branches/opera 명령 과동일 하다. 이명 령은브 랜치를 
Checkout 해주지 않 는다는 것을 주 의해야 한다. 여기서 커 밋하면 opera 브 랜치가 아니라 trunk 브랜치 
에 커밋 된다. 

8.1.8 Subversion 브탠치 넘 Lh 들기 

deceit 명렁은 어떻게 커밋 할 브 탠치를 결정 할까? Git 은 히스 토리에 있는 커밋 중에서 가장 마 지막으 
로 기록된 Subversion 브 랜치를 찾 는다. 즉, 현 브랜치 히스 토리의 커밋 메 시지에 있는 git-svn-id 항 
목을 읽는 것이기 때문에 오직 한 브탠 치에만 전송할 수 있다. 

동시에 여러 브탠 치에서 작업 하려면 Subversion 브 랜치에 dcommit 할수있 는로걸 브 랜치가 필요하 
다. 이 브 탠치는 Subversion 커 밋에서 시 작하는 브탠 치다. 아래와 갈이 opera 브 랜치를 만들면 독립적 
으로 일할수 있다: 



$ git branch opera remotes/opera 



git merge 명 령으로 opera 브 탠치를 trunk 브탠치 (master 브탠치 역할) 에 Merge 한다. 하지만 -m 옵션 

을 주고 적절한 커밋 메 시지를 작 성하지 않으면 아 무짝에 쏠 모없는 "Merge branch opera" 같은 메시 
지 가커밋 된다. 

git merge 명 령으로 Merge 한다는 것에 주목 하자. Git 은 자 동으로 공통 커밋을 찾아서 Merge 에 참고 
하기 때문에 Subversion 에서 하는 것보다 Merge 가 더 잘 된다. 여기서 생 성되는 Merge 커밋은 일반 
격인 Merge 커 밋과다 르다. 이 커밋을 Subversion 서버에 Push 해야 하지만 Subversion 에 서는부 
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모가 2 개인 커밋이 있을 수 없다. 그래서 Push 하면 브탠 치에서 만 들었던 커밋 여 러개가 하나로 합처 
진 (squash 된) 것처럼 Push 된다. 그래서 일단 Merge 하면 취소하 거나해 당브탠 치에서 계속 작업하 
기어 렵다. dcommit 명 령을수 행하면 Merge 한브 탠치의 정보 를어쩔 수없이 잃어 버리게 된다. Merge 
Base 도 찾을 수 없게 된다. dcommit 명령은 Merge 한 것을 git merge —squash 로 Merge 한 것과 똑 같 
이 만들어 버 린다. Branch 를 Merge 한 정보는 겨 장되지 않기 때문에 이 문제를 해결할 방법이 없다. 
문제를 최소화 하려면 trunk 에 Merge 하 자마자 해당 브 탠치를 (여 기서는 opera) 삭 제하는 것이 좋다. 



8.1.9 Subversion 명령 

git svn 명령은 Git 으로 전 향하기 쉽도록 Subversion 에 있는 것과 비숫한 명렁어 를지원 한다. 아마 
여기서 설 명하는 명령은 익숙할 것 이다. 



SVN 형식의 히 스토리 

Subversion 에 익숙한 사람은 Git 히스 토리를 SVN 형 식으로 보고싶 을수도 있다. git svn log 명령 
은 SVN 형 식으로 히스 토리를 보여 준다: 



$ git svn log 


r87 ！ schacon ！ 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009) 
autogen change 




lines 


r86 ！ schacon ！ 2009-05-02 16:00:21 -0700 (Sat, 02 May 2009) 
Merge branch "experiment 1 


I 2 


lines 


r85 ！ schacon ！ 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) 
updated the changelog 


I 2 


lines 



git svn log 명 렁에서 기억해 야할것 은두가 지다. 우선오 프라인 에서동 작한다 는점이 다. SVN 의 svn 
log 명 령어는 히 스토리 데 이터를 조회할 때 서버 가필요 하다. 들째로 이미 서버로 견송한 커밋만 출력 
해 준다. 아직 d C0mm it 명 령으로 서버에 견 송하지 않 은로컬 Git 커 밋은보 여주지 않 는다. Subversion 
서 버에는 있지만 아직 내 려받지 않은 변경 사항도 보 여주지 않 는다. 즉， 현재 알 고있는 Subversion 서 
버 의상태 만보여 준다. 



SVN 어노 테이션 

git svn log 명령이 svn log 명 렁을흥 내내는 것처럼 git svn blame [FILE] 명 령으로 svn annotate 명 
렁을 흥내낼 수 있다. 실행한 결과는 아래와 같다: 
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$ git svn blame README.txt 


2 


temporal Protocol Buffers - Google 1 s data interchange format 


2 


temporal Copyright 2008 Google Inc. 


2 


temporal http ： //code . google . com/ apis/protocolbuf f ers/ 


2 


temporal 


22 


temporal C++ Installation - Unix 


22 


temporal 




temporal 


79 


schacon Committing in git— svn. 


78 


schacon 




temporal To build and install the C++ Protocol Buffer runtime and the Protocol 




temporal Buffer compiler (protoc) execute the following: 




temporal 



다시 한번 말 하지만 이 명령도 아직 서버로 견 송하지 않은 커밋은 보 여주지 않 는다. 

SVN 서 버정보 

svn info 명령은 git svn info 명렁 으로대 신할수 있다: 

$ git svn info 
Path: . 

URL ： https ： //schacon— test . googlecode . com/svn/trunk 

Repository Root: https ： //schacon-test . googlecode . com/svn 

Repository UUID: 4c93b258-373f -1 1 de-be05-5f 7a86268029 

Revision: 87 

Node Kind: directory 

Schedule: normal 

Last Changed Author: schacon 

Last Changed Rev: 87 

Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009) 

blame 이나 log 명령이 오프 라인으 로동작 하듯이 이 명령 도오프 라인으 로동작 한다. 서 버에서 가 장최근 
에 내려받 은정보 를출력 한다. 

Subversion 에서 무시 하는것 무 시하기 

Subversion 저장 소를클 론하면 쏠데 없는 파일을 커 밋하지 않도록 svn: ignore 속성을 .gitignore 파 
일로 만들고 심을것 이다. git svn 에는이 문제와 관련된 명령이 두가지 있다. 하나는 git svn create- 
ignore 명렁 이다. 해당 위치에 커밋할 수있는 .gitignore 파일을 생성해 준다. 

두번째 방법은 git svn show-ignore 명령이 다. .gitignore 에 추가할 목록을 출력해 준다. 프로 젝트의 

exclude 파일로 결과를 리 다이텍 트할수 있다: 
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$ git svn show-ignore > .git/info/exclude 



이렇게 하면 .gitignore 파일로 프로 젝트를 더 립히지 않아도 된다. 혼차 서만 Git 을사 용하는 거라면 다 
른 팀 원들은 프로 젝트에 .gitignore 파일이 있는 것을 싫어 할 수 있다. 

8.1.10 Git-Svn 요약 

git svn 도구는 여 러가지 이유로 Subversion 서버를 사용 해야만 하는 상 황에서 빛을 발 한다. 하지만 
Git 의 모든 장점을 이용할 수는 없다. Git 과 Subversion 은 다르기 때문에 혼란이 빚어질 수도 있다. 이 
런 문제에 빠지지 않기 위해서 다음 가이드 라인을 지켜야 한다: 

• Git 히스 토리를 일직 선으로 유지 하라. git merge 로 Merge 커밋이 생기지 않도록 하라. Merge 

말고 Rebase 로 변경 사항을 Master 브 랜치에 적용 하라. 
- 따로 Git 저장소 서버를 두지 말라. 클론을 빨리 하기 위해서 잠깐 하나 만들어 쓰는 것은 무방하 

나 결대로 Git 서버에 Push 하지는 말아야 한다. pre-receive 흑에서 git-svn-id 가들어 있는커 

밋 메 시지는 거 절하는 방법도 괜 찮다. 

이러한 가이드 라인을 잘 지키면 Subversion 서버도 쏠만 하다. 그래도 Git 서버를 사용할 수 있으면 
Git 서버 를사용 하는것 이휠썬 좋다. 



8.2 Git 으로 옮기기 

다른 VCS 를 사 용하는 프로 젝트를 Git 으로 옮기고 싶다면 우선 프로 젝트를 Git 으로 이전 (Migrate) 해 
야 한다. 이번질 에서는 Git 에들어 있는 Importer 를 살펴보 고직집 Importer 를 만드는 방법을 알아본 
다. 

8.2.1 가 져오기 

많이 사 용하는 Subversion 과 Perforce 프로 젝트를 이 전하는 방법을 살펴 보자. 이 두 VCS 에서 Git 으 
로 이 전하고 자하는 사람이 많고 Importer 도 이미 Git 에 들어 있다. 

8.2.2 Subversion 

git svn 을 설명하 는결을 읽었으 면쉽게 git svn clone 명렁으 로저장 소를가 져올수 있다. 가 겨오고 

나서 Subversion 서버는 중 지하고 Git 서버를 만들고 사 용하면 된다. 만약 히 스토리 정보가 필 요하면 
(느린 ) Subversion 서버 없이 로 컬에서 조 회할수 있다. 

우선 가져 오기에 시간이 많이 드니까 일단가 져오기 를시작 하자. 이 가 져오기 기능에 문 제가좀 있다. 
첫 번째 문제는 Author 정보 이다. Subversion 에서는 커밋 하려면 해당 시스템 계정이 있어야 한다. 

blame 이나 git svn log 같은명 렁에서 schacon 이라는 이름을 봤을것 이다. 이 정보를 Git 형식의 정보로 

변경 하려면 Subversion 사 용자와 Git Author 를 연결시 켜줘야 한다. Subversion 사용자 이름과 Git 
Author 간에 연결을 해줘서 이 Author 정보를 Git 스 타일의 Author 정보로 변경 한다. users.txt 라는 
파일을 아래와 같이만 든다: 



213 



8 장 Git 으로이 견하기 



Scott Chacon Pro Git 



schacon = Scott Chacon 〈schacon@geemail.com〉 
seise = Someo Nelse <selse@geemail . com> 

SVN 에 기록된 Author 이름 을아래 명령으 로조회 한다: 

$ svn log A / — xml ！ grep — P " A <author" ！ sort — u ！ \ 

perl -pe ' s/<author>( .*?)<\/author>/$1 = /' > users.txt 

우선 XML 형 식으로 SVN 로그를 출력 하고, 거기서 Author 정보만 찾고, 중복된 것을 제거 하고, XML 
태 그는버 린다. 물론 gre P ， sort, perl 명렁 이동작 하는시 스템에 서만이 명 령을사 용할수 있다. 이 결과 
에 Git Author 정보를 더해서 users.txt 를 만 든다. 

이 파일을 git svn 명렁에 견 달하면 보다 정확한 Author 정보를 Git 저 장소에 남길 수 있다. 그리고 git 
svn 의 clone 이나 init 명령에 -no-metadata 옵션을 주면 Subversion 의 메타데 이터를 저 장하지 않는 
다. 해당 명렁은 아래와 같다: 

$ git svn clone http ： //my-proj ect . googlecode . com/ svn/ \ 

―— authors-f ile=users . txt ―— no— metadata — s my— project 

my _project 디롁 토리에 진짜 Git 저 장소가 생성 된다. 결과는 아래와 같지 않고: 

commit 37efa680e8473b61 5de980fa93594421 5428a35a 

Author: schacon <schacon@4c93b258-373f-1 1de-be05-5f7a86268029> 

Date: Sun May 3 00:12:22 2009 +0000 

fixed install - go to trunk 

git— svn— id ： https ： 1 1 my-proj ect . googlecode . com/svn/trunk@94 4c93b258-373f-1 1 de- 
be05-5f7a86268029 



아래와 같다: 

commit 03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2 
Author: Scott Chacon <schacon@geemail . corn) 
Date: Sun May 3 00:12:22 2009 +0000 



fixed install - go to trunk 




Author 정보가 휠썬 Git 답고 git-svn-id 항 목도기 록되지 않 았다. 
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이제 뒷 정리를 해야 한다. git svn 이 만들어 준 이상한 브 랜치나 태그를 제거 한다. 우선 이상한 리모트 
태그를 모두 진짜 Git 태그로 옮 긴다. 그리고 리모트 브 탠치도 로걸 브 랜치로 옮 긴다. 
아래와 같이 태그를 진정한 Git 태그로 만 든다: 

$ git for- each- ref refs/ remotes/ tags ！ cut — d I — f 4— ！ grep - 
v @ ！ while read tagname; do git tag "$tagname" "tags/$tagname"; git branch — r — d "tags/ 
$tagname"; done 



t a g S / 로시작 하는리 모트브 탠치를 가져다 (Lightweight) 태그 로만들 었다. 

refs/remotes 밀에 있는 레퍼 런스는 견부 로컬 브 탠치로 만 든다: 

$ git for- each- ref refs/ remotes ！ cut — d I — f 3— ！ grep ― 
v @ ！ while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch - 
r — d "$branchname"; done 

이제 모든 태그와 브 탠치는 진짜 Git 태그와 브 탠치가 됐다. Git 서버를 새로 추가를 하고 지 금까지 작 
업 한것을 Push 하 는일이 남 았다. 아래 처럼 리모 트서버 를추가 한다: 

$ git remote add origin git@my-git-server:myrepository.git 

분명 모든 브 탠치와 태그를 Push 하고 싶을 것 이다: 

$ git push origin —all 



모든 브 탠치와 태그를 Git 서버로 깥 끔하게 잘 옮 겼다. 
8.2.3 Perforce 

이제 Perforce 차 례다. Preforce Importer 도 Git 에 들어 있다. Git 1.7.11 이전 버전을 사 용한다 
면 소스 코드의 contrib 에 포 함되어 있다. 이런 경 우라면 Perforce Importer 를사 용하기 위해 우선 
git.kernel.org 에서 Git 소스 코드를 가 져와야 한다: 

$ git clone git://git .kernel .org/pub/scm/git/git. git 
$ cd git/contrib/fast— import 



git- P 4 라는 Python 스크 립트는 fast-import 디텍 토리에 있다. 그리고 Python 과 P 4 가 설치돼 있어야 
이 스크 립트가 동작 한다. Perforce Public Depot 에 있는 Jam 프로 젝트를 Git 으로 옮겨 보자. 우선 
Perfoce Depot 의 주소를 P4P0RT 환경 변수에 설정 한다: 
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$ export P4P0RT=public . perforce . com ： 1 666 



git- P 4 clone 명 령으로 Perforce 서 버에서 Jam 프로 젝트를 가겨 온다. 이 명렁에 Depot, 프 로젝트 경 
로， 프로 젝트를 가겨올 경로를 주면 된다: 

$ git-p4 clone //public/ jam/src@all /opt/p4import 
Importing from //public/ jam/src@all into /opt/p4import 
Reinitialized existing Git repository in /opt/ p4import/ . git/ 
Import destination: refs/remotes/p4/master 
Importing revision 4409 (100%) 




/opt/ P 4import 디롁 토리로 이 동해서 git log 명렁을 실 행하면 프 로젝트 정보를 볼 수 있다: 



$ git log -2 

commit 1 fd4ec1261 71 790efd2db83548b85b1 bbbc07dc2 
Author: Perforce staff <support@perf orce . com> 
Date: Thu Aug 19 10:18:45 2004 -0800 

Drop 'rc3' moniker of jam-2.5. Folded rc2 and rc3 RELNOTES into 
the main part of the document. Built new tar/zip balls. 

Only 16 months later. 

[git-p4: depot-paths = "//p 니 blic/jam/src/" : change = 4409] 

commit ca8870db541 a23ed867f38847eda65bf4363371 d 
Author: Richard Geiger 〈rmg@perforce.com〉 
Date: Tue Apr 22 20:51:34 2003 -0800 

Update derived jamgram.c 

[git-p4: depot-paths = "//public/jam/src/" : change = 3108] 



커 밋마다 g it - p4 라는 id 항목이 들어가 있다. 나중에 Perforce Change Number 가 필 요해질 수도 
있으니 커밋에 그대로 유지하 는편이 좋다. 하지만 ID 를지 우고자 한다면 지금하 는것이 가장 좋다. git 

filter-branch 명 렁으로 한방에 삭제 한다: 



$ git filter-branch ―— msg— filter 
sed -e "/ A \[git-p4:/d" 
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Rewrite 1 f d4ed 261 71 790ef d2db83548b85b1 bbbc07dc2 (123/123) 
Ref 'refs/heads/master' was rewritten 



git log 명렁을 실행하 면모든 SHA-1 체 크심이 변경 됐고커 밋메시 지에서 git- P 4 항목 도삭제 된것을 
확 인할수 있다. 

$ git log -2 

commit 1 0a16d60cffca14d454a1 5c61 64378f4082bc5b0 
Author: Perforce staff <support@perf orce . com> 
Date: Thu Aug 19 10:18:45 2004 -0800 

Drop 'rc3' moniker of jam— 2.5. Folded rc2 and rc3 RELNOTES into 
the main part of the document. Built new tar/zip balls. 

Only 16 months later. 

commit 2b6c6db31 1 dd76c34c66ed C40a49405e6b527b2 
Author: Richard Geiger <rmg@perf orce . com> 
Date: Tue Apr 22 20:51:34 2003 -0800 

Update derived jamgram.c 



이제 새 Git 서버에 Push 하면 된다. 

8.2.4 직집 Importer 만들기 

사 용하는 VCS 가 Subversion 이나 Perforce 가 아니면 인터 넷에서 적당한 Importer 를 찾 아봐야 한 
다. CVS, Clear Case, Visual Source Safe 같은시 스템용 Importer 가 좋은게 많다. 심지어 단순히 
디 롁토리 아카 이브용 Importer 에도 좋은게 있다. 사 람들이 잘 안쓰는 시 스템을 사 용하고 있는데 적당 
한 Importer 를 못 찾 았거나 부 족해서 좀 더 고처야 한다면 git fast-import 를 사용 한다. 이명 령은표 
준입 력으로 데 이터를 입력받 는데, 9 장에서 배우는 저수준 명 렁어와 내부 객체를 직집 다루는 것보다 휠 
썬 쉽다. 먼저 사 용하는 VCS 에서 필요한 정보를 수 집해서 표준출 력으로 출 력하는 스크 립트를 만 든다. 
그리고 그 결 고ᅡ를 git fast-import 의 표준입 력으로 보낸다 (pipe). 

간단한 Importer 를 작성해 보자. back_YYYYjm— dd 라는 디롁 토리에 백업 하면서 프로 젝트를 진 행하는 
예제를 보자. Importer 를 만들 때 디 텍토리 상태는 아래와 같다: 

$ Is /opt/import_from 

back_2O09_01_02 

back_2G09_01_04 

back_2G09_01_14 

back_2009_02_03 
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current 




Importer-! 만들기 전에 우선 Git 이 어떻게 데이터 를겨장 하는지 알아야 한다. 이미 알고 있듯이 Git 
은 기본 적으로 스 냅샷을 가 리키는 커밋 개체가 연결된 리스트 이다. 스 냅샷이 뭐고, 그걸 가 리키는 커밋 

은 또 뭐고, 그 커밋의 순서가 어떻게 되는지 fast-import 에 알려 줘야 한다. 이 것이 해야할 일의 견부 
다. 그러면 디텍토 리마다 스 냅샷을 만 들고， 그 스 냅샷을 가 리키는 커밋 개체를 만 들고, 이견 커밋과 연 
결시 킨다. 

7 장의 "정책 구현 하기" 결에서 했던 것 처럼 Ruby 로 스크 립트를 작성 한다. 필자는 Ruby 를 많이 사용 
하기도 하고 Ruby 가 읽기도 쉽다. 하지만 자 신에게 익숙한 것을 사 용해서 표준출 력으로 격결한 정보만 
출력할 수 있으면 된다. 그리고 윈도 에서는 줄바꿈 문자에 CR(Carriage Return) 문 자가들 어가지 않 
도록 주 의해야 한다. git fast-import 명렁은 윈도 에서도 줄바꿈 문자로 CRLF 문자가 아니라 LF(Line 
Feed) 문차 만허용 한다. 

우선 해당 디텍 토리로 이 동해서 어떤 디텍 토리가 있는지 살펴 본다. 하위 디롁토 리마다 스냅샷 하나가 
되 고커밋 하나가 된다. 하위 디 텍토리 를이동 하면서 필요 한정보 를출력 한다. 기 본격인 로직은 아래와 
같다: 



last_mark = nil 

# loop through the directories 
Dir.chdir(ARGV[0]) do 
Dir. glob("*"). each do Idir! 
next if File.file?(dir) 

# move into the target directory 
Dir.chdir(dir) do 

last— mark = print_export(dir, last— mark) 
end 



end 
end 




각 디롁토 리에서 print— export 를 호출 하는데 이 함수는 아규 먼트로 디롁 토리와 이견 스냅샷 Mark 를 

견 달받고 현 스냅샷 Mark 를 반환 한다. 그래서 격절히 연결 시길 수 있다. fast-import 에서 "Mark" 는 
커 밋의식 별자를 말한다 커밋 을하나 만들면 Mark 도같이 만들어 이 Mark 로 다른커 밋과연 결시킨 

다. 그래서 print— export 에서 우선 해야 하는 일은 각 디 롁토리 이 름으로 Mark 를 생 성하는 것 이다: 



mark = convert_dir_to_mark(dir) 



Mark 는정 수값을 사용해 야하기 때문에 디롁 토리를 배열에 담 고그인 덱스를 Mark 로사용 한다. 아 
래와같 이작성 한다: 
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$marks = [ ] 

def convert_dir_to_mark(dir) 
if !$marks.include?(dir) 

$marks « dir 
end 

($marks.index(dir) + 1 ) . to_s 



end 




각 커밋을 가 리키는 정수 Mark 를 만 들었고 다음은 커밋 메타데 이터에 넣을 날짜 정보가 필요 하다. 이 

날짜는 디 텍토리 이름에 있는 것을 가겨 다사용 한다. print— export 의 두 번째 줄은 아래와 같다: 

date = convert_dir_to_date(dir) 

convert_dir— to— date 는 아래와 같이 정의 한다: 

def convert_dir_to_date(dir) 
if dir = 'current 1 

return Time. now ( ) .to_i 
else 

dir = dir.gsub( 'back—' , 1 1 ) 
(year, month, day) = dir.split( '_' ) 
return Time.locaKyear, month, day). to— i 
end 
end 



시간는 정수 형태로 반환 한다. 마지 막으로 메타 정보에 필요한 것은 Author 인데 이 것은 전역 변수 하 
나로 설정해 서사용 한다: 

$author = "Scott Chacon <schacon@example . com> 1 



이제 Importer 에서 출력할 커밋데 이터는 다준비 했다. 이제 출력해 보자. 사 용할브 탠치, 해당 커밋과 
관련된 Mark, 커미터 정보, 커밋 메 시지, 이견 커밋 을출력 한다. 코드로 만들면 아래와 같다: 

# print the import information 
puts 'commit ref s/heads/master' 
puts 'mark : 1 + mark 

puts "committer #{$author} #{date} -0700" 
export_data( 1 imported from ' + dir) 
puts 'from ： 1 + last_mark if last— mark 
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우선 시간대 (—0700) 정보는 편의상 하드코 딩으로 처리 했다. 각자의 시 간대에 맞는 오 프셋을 설정해 
야 한다. 커밋 메 시지는 아래와 같은 형식을 따라야 한다: 



data (size)\n(contents) 



이 형식은 'data' 라는 단어， 읽을 데 이터의 크기， 즐바꿈 문자， 실 데 이터로 구성 된다. 이 형식을 여러 

곳에서 사 용해야 하으로 export— data 라는 메 소드로 만들어 놓는게 좋다: 



def export_data( string) 

print "data #{string.size}\n#{string} 
end 



이제 남은 것은 스 냅샷에 파일 내용를 포함 시키는 것 뿐 이다. 디텍 토리로 구분돼 있기 때문에 어렵지 않 

다. 우선 deleteall 이라는 명렁을 출 력하고 그 뒤에 모든 파일의 내용을 출력 한다. 그런면 Git 은 스냅샷 
을 잘겨장 한다: 

puts "deleteall 1 

Dir. globC 1 **/*"). each do |file| 

next if ！ File. file? (file) 

inline— data(file) 
end 

중요: 대 부분의 VCS 는 리 비견을 커 밋간의 변화로 생 각하기 때문에 fast-import 에 추가 / 삭제 / 변경된 
부분만 입력할 수도 있다. 스냅샷 사이의 차이를 구해서 fast-import 에 넘길 수도 있지만 휠썬 복잡하 
다. 줄 수있는 데 이터는 견부 Git 에 줘서 Git 이 계 산하게 해야 한다. 꼭 이렇게 해야 한다면 어떻게 데이 
터를전 달해야 하는지 fast-import 의 ManPage 를참고 하라. 

파일 정보와 내용은 아래와 같은 형 식으로 출력 한다: 



M 644 inline path/to/file 
data (size) 
(file contents) 




644 는 파일의 모드를 나 타낸다 (실 행파일 이라면 755 로 지정 해줘야 한다 ). inline 은 다음 줄 부터는 
파일 내용 이라는 말하는 것 이다. inline.data 메 소드는 아래와 같다: 

def inline— data(file, code = 'M' , mode = 1 644 1 ) 

content = File.read(f ile) 

puts "#{code} #{mode} inline #{file}" 

export— data ( content ) 
end 
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파일 내용은 커밋 메 시지랑 같은 방법을 사 용하기 때문에 앞서 만들어 놓은 export— data 메 소드를 다시 
이용 한다. 

마지 막으로 다음 커밋에 사용할 현 Mark 값을 반환 한다: 



return mark 



증요: 윈 도에서 실행할 때는 추가 작업이 하나 더 필요 하다. 앞에서 얘기 했지만 윈도는 CRLF 를 사용하 
지만 git fast-import 는 LF 를사용 한다. 이 문제 를해결 하려면 Ruby 가 CRLF 대신 LF 를사용 하도록 
알 려줘야 한다: 



$stdout.binmode 



모든게 끝 났다. 스크 립트를 실 행하면 아래와 같이 출력 된다: 



$ ruby import . rb /opt/import_from 
commit refs/heads/master 
mark :1 

committer Scott Chacon 〈schacon@geemail.com〉 1230883200 -0700 
data 29 

imported from back_2009_01_02deleteall 
M 644 inline file.rb 
data 12 
version two 

commit refs/heads/master 
mark :2 

committer Scott Chacon 〈schacon@geemail.com〉 1231056000 -0700 
data 29 

imported from bac k_2009_01 _04f rom :1 
deleteall 

M 644 inline file.rb 

data 14 

version three 

M 644 inline new . rb 

data 16 

new version one 
(...) 



디 롁토리 를하나 만들고 git init 명렁을 실행해 서옮길 Git 프로젝 트를만 든다. 그리 고그프 로젝트 
디롁 토리로 이 동해서 이 명렁의 표준 출력을 git fast-import 명렁의 표준입 력으로 연 결한다 (pipe). 
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$ git init 

Initialized empty Git repository in /opt/import— to/. git/ 
$ njby import . rb /opt/import— from ！ git fast-import 
git-fast-import statistics: 



Alloc 'd objects: 


5000 












Total objects '• 


18 


( 


1 


duplicates 




) 


blobs ： 




( 


1 


duplicates 


0 


deltas) 


trees ： 


6 


( 


0 


duplicates 


1 


deltas) 


commits: 




( 


0 


duplicates 


0 


deltas) 


tags ： 


0 


( 


0 


duplicates 


0 


deltas) 


Total branches: 


1 


( 


1 


loads ) 






marks: 


1024 


( 




unique ) 






atoms: 














Memory total: 


2255 


KiB 










pools: 


2098 


KiB 










objects: 


156 


KiB 











pack_report 
pack— report 
pack— report 
pack— report 
pack— report 
pack— report 
pack_report 



getpagesize( ) = 4096 

core.packedGitWindowSize = 33554432 

core. packedGit Limit = 268435456 

pack_used_ctr = 9 

pack_mmap_calls = 5 

pack_open— windows = 1 

pack_mapped = 1356 



1 

1356 



성공 격으로 끝나면 여기서 보 여주는 것처럼 어떻게 됐는지 통게 를보여 준다. 이 경우엔 브탠치 1 개와 
커밋 5 개 그리고 개체 1 8 개가 임포트 됐다. git log 명 렁으로 히 스토리 조회가 가능 하다: 



$ git log -2 

commit 1 0bfe7d22ce1 5ee25b60a824c89821 57ca593d41 
Author: Scott Chacon 〈schacon@example.com〉 
Date: Sun May 3 12:57:39 2009 -0700 

imported from current 

commit 7e51 9590de754d079dd73b44d695a42c9d2df452 
Author: Scott Chacon <schacon@example . com) 
Date: Tue Feb 3 01:00:00 2009 -0700 



imported from back— 2009— 02— 03 
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이 시점에 서는아 무것도 Checkout 하지 않았기 때문에 워킹 디텍 토리에 아직 아무 파일도 없다. master 

브 탠치로 Reset 해서 파일을 Checkout 한다: 



$ Is 

$ git reset —― hard master 

HEAD is now at 10bfe7d imported from current 

$ Is 

file.rb lib 



fast-import 명 령으로 많은 일을 할 수 있다. 모드를 설정 하고, 바 이너리 데 이터를 다 루고, 브 탠치를 여 

러 개 다 루고, Merge 하고， 태그를 달고, 진행 상황을 보여 주고， 등등 무수히 많은 일을 할 수 있다. Git 

소스의 contrib/fast-import 디텍 토리에 복잡한 상황을 다루는 예제가 많다. 그 중 여기서 설명한 git- 
P 4 스크립 트가좋 은예제 이다. 



8.3 요약 

Subversion 프로젝 트에서 Git 을 사용하 거나， 다른 VCS 저 장소를 Git 저 장소로 손실 없이 옮기는 방 
법에 대해 알아 봤다. 다음장 에서는 Git 내부를 까 본다. 필요 하다면 바이트 하 나하나 다루는 것도 가능 
하다. 
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여 기까지 다 읽고 왔든 바로 9 장부터 보기 시작 했든지 간에 이제 마지막 장 이다. 9 장은 Git 이 어떻게 
구현돼 있고 내부 격으로 어떻게 동작 하는지 설명 한다. Git 이 얼마나 유 용하고 강 력한지 이해 하려면 9 
장의 내용을 꼭 알아야 한다. 9 장은 초보 자에게 너무 혼란 스럽고 불 필요한 내용 이라고 이야 기하는 사 
람들도 있다. 그래서 필자는 본 내용을 책의 가장 마 지막에 두었고 독자가 스스로 먼저 볼지 나중에 볼 
지선 택할수 있도록 했다. 

자이제 본격 적으로 살펴 보자. 우선 Git 은기본 격으로 Content-addressable 파일 시스 템이고 그 위 
에 VCS 사용자 인터페 이스가 있는구 조다. 뭔 가깥끔 한정의 는아니 지만, 이 말이 무슨 의미인 지는차 
차알게 된다. 

Git 초 기에는 (1.5 이전 버견) 사용 자인터 페이스 가휠썬 복잡했 었다. VCS 가아 니라파 일시스 템을강 
조했기 때문이 었다. 최근 S 년간 Git 은 다튼 VCS 처럼 쉽고 간 결하게 사용자 인터페 이스를 다듬어 왔 
다. 하 지만, 여전히 복 잡하고 배우기 어렵 다는선 입견이 있다. 

우선 Content-addressable 파일 시 스템은 정말 대단한 것 이므로 먼저 다 툰다. 그리고 나서 데이터 
견송 원리를 배우고 마지 막에는 저 장소를 관 리하는 법까지 배 운다. 



9.1 Plumbing 명령과 Porcelain 명령 

이 책 에서는 checkout, branch, remote 같은 30 여 가지의 Git 명령을 사용 했다. Git 은 사실 사용자 친화 
격인 VCS 이기 보다는 VCS 로 도사용 할수있 는툴킷 이다. 저수준 명 령어가 매우 많아서 겨 수준의 일도 
쉽게 처리할 수 있다. 명 령어여 러개를 Unix 스 타일로 함께 엮어서 실행 하거나 스크립 트에서 호출할 
수 있도록 설계 됐다. 이러한 저 수준의 명 령어는 "Plumbing" 명령 어라고 부르고 좀 더 사용 자에게 친 
숙한사 용자용 명 령어는 "Porcelain" 명령어 라고부 른다. 

이 책의 앞여덟 장은 Porcelain 명렁어 만사용 했다. 하 지만, 이 장 에서는 저수준 명령인 Plumbing 명 
렁어을 주로 사용 한다. 이 명 렁으로 Git 의 내부 구조에 집근할 수 있고 실제로 왜, 그렇게 작동하 는지도 
살 펴볼수 있다. Plumbing 명령어 은직집 커 맨드라 인에서 실행하 기보다 새로운 도구를 만들거 나각자 
필요한 스크 립트를 작성할 때 사용 한다. 

새 로만든 디텍토 리나이 미파일 이있는 디텍토 리에서 git init 명 령을실 행하면 Git 은 데이터 를저장 
하고관 리하는 .git 디텍토 리를만 든다. 이 디텍토 리를복 사하기 만해도 저장소 가백업 된다. 이 장은 
기본 적으로 이 디텍 토리에 대한 내용을 설명 한다. 디 텍토리 구조는 아래와 같다: 

$ Is 
HEAD 
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branches/ 

config 

description 

hooks/ 

index 

info/ 

objects/ 

refs/ 



이 외에 다른파 일들이 더 있 지만이 상태가 git init 을한 직후에 보 이는새 저 장소의 모습 이다. 
branches 디텍 토리는 Git 의 예견 버 견에서 만사 용하고 description 파일 은기본 적으로 GitWeb 프로그 
램에 서만사 용하기 때문에 이 들은무 시해도 된다. config 파일에 는해당 프로젝 트에만 적용되 는설정 
옵션이 들어 있다. info 디텍토 리는. gitignore 파 일처럼 무시할 파일의 패턴 을적어 두는곳 이다. 하지 
만 .gitignore 파 일과는 달리 Git 으로 관 리되지 않 는다. hook 디텍토 리에는 클라 이언트 흑이나 서버흑 
을 넣 는다. 관련 내용은 7 장에서 설명 했다. 

이제 남은네 가지 항 목은모 두중요 한항목 이다. HEAD 파일, index 파일, objects 디텍 토리, refs 디텍토 
리가남 았다. 이 네 항목이 Git 의 핵심 이다. objects 디텍토 리는모 든컨텐 트를저 장하는 데이터 베이스 

이고 re f s 디텍토 리에는 커밋 개체의 포 인터를 저장한 다. head 파일은 현재 Checkout 한 브 탠치를 가리 
키고 index 파일은 Staging Area 의 정보를 겨장 한다. 각 결마다 주제를 나눠서 Git 이 어떻게 동 작하는 
지 자세히 설명 한다. 



9.2 Git 개체 

Git 은 Content-addressable 파일 시스템 이다. 이게 무슨 말이나 하면 GitO| 단순한 Key—Value 데 
이터 저장 소라는 것 이다. 어떤 형식의 데이 터라도 집어넣 을수있 고해당 Key 로 언 제든지 데 이터를 다 
시 가 져올수 있다. Plumbing 명령어 hash-object 에 데이터 를주면 .git 디텍 토리에 저장 하고그 key 
를 알려 준다. 우선 Git 저 장소를 새로 만들고 objects 디텍 토리에 뭐가 들어 있는지 확인 한다: 



$ mkdir test 
$ cd test 
$ git init 

Initialized empty Git repository in /tmp/test/.git/ 

$ find .git/objects 

.git/objects 

.git/objects/info 

.git/objects/pack 

$ find .git/objects -type f 

$ 



아 무것도 없다. Git 은 objects 디텍 토리를 만들고 그 밀에 pack 과 info 디롁 토리도 만 든다. 아직 빈 디 
롁토리 일뿐파 일은아 무것도 없다. Git 데 이터베 이스에 텍스트 파일을 저장해 보자: 
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$ echo 'test content' ！ git hash-object — w ―— stdin 
d670460b4b4aece591 5caf 5c68d12f 560a9fe3e4 



이 명렁은 표준입 력으로 들어오 는데이 터를저 장할수 있다. 옵션 을줘 야실제 로저장 한다. 1 가없 

으면 저 장하지 않고 key 만 보여 준다. 그리고 -stdin 옵션을 주면 표준입 력으로 입 력되는 데 이터를 읽 

는다. 이 옵션이 없으면 파일 경로를 알 려줘야 한다. hash-object 명렁이 출 력하는 것은 40 자 길이의 체 
크심 해 시다. 이 해시 는해더 정보와 데이터 모두에 대한 SHA-1 해시 이다. 해더 정보 는차차 자세히 살 
펴볼 것 이다. Git 이 저장한 데 이터를 알아 보자: 



$ find .git/objects -type f 

.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 




objects 디텍 토리에 파일이 하나 새로생 겼다. Git 은데이 터를저 장할때 데 이터와 해더로 생성한 
SHA-1 체크 심으로 파일 이름을 것 는다. 해시의 처음 두 글자를 따서 디 텍토리 이름에 사 용하고 나머 
지 38 글자 를파일 이름에 사용 한다. 데이터 는새로 만든 파일에 저장 한다. 

cat-file 명령으 로저장 한데이 터를불 러을수 있다. 이 명렁은 Git 개 체를살 펴보고 싶을때 맥 가이버 
칼처럼 사 용할수 있다. cat-file 명령에 -p 옵션 을주면 파일 내용이 출력 된다: 

$ git cat-file -p d670460b4b4aece591 5caf 5c68d1 2f 560a9f e3e4 
test content 



다시 한 번 데 이터를 Git 저 장소에 추 가하고 불러와 보자. Git 이 파일 버견을 관 리하는 방식을 이해할 
수 있도록 가상의 상황을 만들어 살펴 본다. 우선 새 파일을 하나 만들고 Git 저 장소에 저장 한다: 



$ echo 'version 1 1 > test .txt 
$ git hash-object — w test .txt 
83baae61804e65cc73a7201a7252750c76066a30 




그리고 그 파일을 수 정하고 다시 저장 한다: 



$ echo 'version 2' > test.txt 
$ git hash-object — w test.txt 
1 f7a7a472abf3dd9643fd61 5f6da379c4acb3e3a 



이제 데이터 베이스 에는데 이터가 두가지 버 전으로 저장돼 있다: 
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$ find .git/objects -type f 

.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a 
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 



파일의 내용을 첫 번째 버 견으로 되 돌리려 본다: 



$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt 
$ cat test.txt 
version 1 



다 시두번 째버전 을격용 한다: 



$ git cat-file -p 1 f 7a7a472abf 3dd9643f d61 5f 6da379c4acb3e3a > test.txt 
$ cat test.txt 
version 2 



파일의 SHA-1 키를 외워서 사 용하는 것은 너무 어 렵다. 게다가 원래 파일의 이름은 저장 하지도 않았 
다. 단지 파일 내용 만저장 했을뿐 이다. 이런 종류의 개체를 Blob 개체 라고부 른다. cat-file -t 명령으 
로 해당 개체 가무슨 개 채인지 확인할 수 있다: 



$ git cat-file -t 1 f 7a7a472abf 3dd9643f d61 5f 6da379c4acb3e3a 
blob 



9.2.1 Tree 개체 

다음은 Tree 개체 를살펴 보자. 이 Tree 개체에 파일 이름 을저장 한다. 파일 여러 개를한 끼번에 저장할 
수도 있다. Git 은 유닉스 파일 시 스템과 u ᅵ숫한 방 법으로 저장 하지만 좀 더 단순 하다. 모든 것을 Tree 와 
Blob 개체로 저장 한다. Tree 는유 닉스의 디텍 토리에 대 응되고 Blob 은 Inode 나 일반 파일에 대응된 
다. Tree 개체 하나는 항목을 여러 개 가질 수 있다. 그리고 그 항 목에는 Blob 개체나 하위 Tree 개체를 
가 리키는 SHA-1 포 인터, 파일 모드, 개체 타입, 파일 이름이 들어 있다. simplegit 프로 젝트의 마지막 
Tree 개체 를살펴 보자: 



$ git cat-file — p master A {tree} 

100644 blob a906cb2a4a904a152e80877d4088654daad0c859 README 

100644 blob 8f94139338f9404f26296befa88755fc2598c289 Rakefile 

040000 tree 99f 1 a6d1 2cb4b6f 1 9c8655f ca46c3ecf 31 7074eG lib 
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masteriltree} 구문은 master 브 탠치가 가 리키는 Tree 개체를 말 한다. lib 은 디 텍토 리인데 Blob 개체 

가아니 고다른 Tree 개체다 ： 

$ git cat-file -p 99f 1 a6d1 2cb4b6f 1 9c8655f ca46c3ecf 31 7074e0 

100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b simplegit.rb 

Git 이 저장하 는데이 터는대 강그림 9-1 과 같다. 



tree 



y ~ I ~ V 

README Rakefile lib 









| blob J 




| blob J 




| tree J 



simplegit.rb 



blob 



그림 9.1 ： 단 순화한 Git 데이터 모델 

직접 Tree 개체를 만들어 보자. Git 은 일반 격으로 Staging Area (Index) 의 상 태대로 Tree 개체를 만 
들고 기록 한다. 그래서 Tree 개체를 만 들려면 우선 Staging Area 에 파일을 추 가해서 Index 를 만들어 
야 한다. 우선 Plumbing 명렁어 update-index 로 test.txt 파일 만들어 있는 Index 를만 든다. 이 명령 
어는 파일을 인위 적으로 Staging Area 에 추 가하는 명 령다. 아직 Staging Area 에 없는파 일이기 때문 
에 -add 옵선 을꼭줘 야한다 (사실 아직 Staging Area 도설 정하지 않았다 ). 그리고 디텍 토리에 있는 

파일이 아 니라데 이터베 이스에 있는파 일을추 가하는 것이기 때문에 -cacheinfo 옵션이 필요 하다. 파 
일 모드, SHA-1 해시, 파일 이 름정보 도입력 한다: 

$ git update-index ᅳ add ―— cacheinfo 1 00644 \ 
83baae61804e65cc73a7201 a7252750c76066a30 test . txt 

여기서 파일 모드는 보통의 파일을 나 타내는 100644 로 지정 했다. 실 행파일 이라면 100755 로 지 정하고 
심볼릭 링 크라면 120000 으 로지정 한다. 이런 파일 모드 는유닉 스에서 가 져오긴 했 지만, 유닉스 모드를 
전부 사용하 지는않 는다. Blob 파일 에는이 세 가지 모드 만사용 한다. 디텍 토리나 서브모 듈에는 다른 
모드 를사용 한다. 

Staging Area 를 Tree 개체로 저장할 때는 write-tree 명렁을 사용 한다. write— tree 명령은 Tree 개체 
가 없으면 차 동으로 생성 하므로 옵션이 필요 없다: 

$ git write-tree 

d8329fc1cc938780ffdd9f94e0d364e0ea74f579 

$ git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f 579 

100644 blob 83baae61 804e65cc73a7201 a7252750c76066a30 test.txt 
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$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f 579 
tree 



파일을 새로 하나 추 가하고 test.txt 파일도 두 번째 버전을 만 든다. 그리고 나서 Tree 개체를 만 든다: 

$ echo 'new file' > new.txt 
$ git 니 pdate~index test.txt 
$ git update— index ―— add new.txt 



새 파일인 new.txt 와 새로운 버견의 test.txt 파 일까지 Staging Area 에 추가 했다. 현재 상태의 
Staging Area 를 새로운 Tree 개 체로기 록하면 어떻게 보 이는지 살펴 보자: 

$ git write—tree 

01 55eb4229851 634a0f 03eb265b69f 5a2d56f 341 
$ git cat-file -p 01 55eb4229851 634a0f 03eb265b69f 5a2d56f 341 
100644 blob f a49b077972391 ad58037050f 2a75f 74e3671 e92 new.txt 
100644 blob 1 f 7a7a472abf 3dd9643f d61 5f 6da379c4acb3e3a test.txt 



이 Tree 개체에 는파일 이두개 있고 test.txt 파일의 SHA 값도 두번째 버전인 If7a7ai 이다. 재 미난걸 
해 보자. 처음에 만든 Tree 개체를 하위 디롁 토리로 만들 수 있다. read-tree 명 렁으로 Tree 개체를 읽 
어 Staging Area 에 추가 한다. -prefix 옵션을 주면 Tree 개체를 하위 디텍 토리로 추가할 수 있다. 

$ git read-tree — prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579 
$ git write—tree 

3c4e9cd789d88d8d89c1073707c3585e41b0e614 
$ git cat-file -p 3c4e9cd789d88d8d89c 1 O73707c3585e41 b0e61 4 
040000 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 bak 
100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt 
100644 blob 1 f 7a7a472abf 3dd9643f d61 5f 6da379c4acb3e3a test.txt 

이 Tree 개체로 워킹 디롁 토리를 만들면 파일 두 개와 bak 이라는 하위 디롁 토리가 생긴다 ■ 그리고 bak 
디 롁토리 안에는 test.txt 파일 의처음 버견이 들어 있다. 그림 9-2 와같은 구조로 데이터 가저장 된다. 

9.2.2 커 밋개체 

각기 다른 스 냅샷을 나 타내는 Tree 개체를 세 개 만들 었다. 하 지만， 여견히 이 스 냅샷을 불러 오려면 
SHA-1 값을기 억하고 있어야 한다. 스 냅샷을 누가， 언제， 왜 저장했 는지에 대 한정보 는아예 없다. 이 
런정 보는커 밋개체 에저장 된다: 
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d8329f 

tree 



test.txt 
I 

83t>aae 

"version 1 ' 



그림 9.2: 현재 Git 데이 터구조 

커밋 개체는 commit—tree 명 렁으로 만 든다. 이 명렁에 커밋 개체에 대한 설명과 Tree 개체의 SHA—1 값 
한 개를 님 긴다. 앞서 저장한 첫 번째 Tree 를 가지고 아래와 같이 만들어 본다: 

$ echo 'first commit 1 ！ git commit— tree d8329f 
fdf4fc3344e67ab068f836878b6c4951 e3b1 5f3d 

새로 생긴 커밋 개체를 cat-file 명 렁으로 확인해 보자: 

$ git cat-file -p fdf4fc3 

tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 

author Scott Chacon <schacon@gmail.com> 1243040974 -0700 

committer Scott Chacon <schacon@gmail .com) 1243040974 -0700 

first commit 



커밋 개체의 형식은 간단 하다. 해당 스냅 샷에서 최상단 Tree 를 (역주 - 루트 디 텍터리 같은) 하나 가리 

킨다. 그리고 user. name 과 user. email 설 정에서 가져온 Author/Committer 정보, 시간 정보， 그리고 
한 줄 띄운 다음 커밋 메 시지가 들어 간다. 

이제 커밋 개체를 두 개 더 만들어 보자. 각 커밋 개체는 이견 개체를 가리 키도록 한다: 

$ echo 'second commit 1 ！ git commit-tree 0155eb — p fdf4fc3 

Cac0cab538b970a37ea1e769cbbde608743bc96d 

$ echo 'third commit 1 ！ git commit-tree 3c4e9c — p cacGcab 

1 a41 0efbd1 3591 db07496601 ebc7a059dd55cfe9 

세 커밋 개체는 각각 해당 스 냅샷을 나 타내는 Tree 개체를 하나씩 가 리키고 있다. 이상해 보이 겠지만 
우리 는진짜 Git 히 스토리 를만들 었다. 마지 막커잇 개체의 SHA—1 값 을주고 git log 명 렁을실 행하면 
아 래와같 이출력 한다: 



|3c4e9c 
tree 



y ~ i ~ 

new.txt test.txt 



bak 



|fa49b0 

"new file" 



[If 7。 7。 

"version 2" 
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$ git log —stat 1a410e 




commit 1 a41 0efbd1 3591 dbO7496601 ebc7a059dd55cfe9 




Author: Scott Chacon 〈schacon@gmail.com〉 




Date: Fri May 22 18:15:24 2009 -0700 




third commit 




bak/test.txt ！ 1 + 




1 files changed, 1 insertions(+) , 0 deletions (- 


ᅵ) 


commit cacOcab538b970a37ea1 e769cbbde608743bc96d 




Author: Scott Chacon <schacon@gmail . com) 




Date: Fri May 22 18:14:29 2009 -0700 




second commit 




new . txt ！ 1 + 




test.txt ！ 2 +— 




2 files changed, 2 insertions(+) f 1 deletions (- 


-) 


commit fdf4fc3344e67ab068f836878b6c4951 e3b1 5f3d 




Author: Scott Chacon <schacon@gmail . com) 




Date: Fri May 22 18：09：34 2009 -0700 




first commit 




test.txt ！ 1 + 




1 files changed, 1 insertions(+) , 0 deletions (- 







놀랍지 않 은가! 방금 우리는 고수준 명령어 없이 저 수준의 명령 으로만 Git 히 스토리 를만들 었다. 지금 
한 일이 git add 와 git commit 명렁을 실 행했을 때 Git 내 부에서 일 어나는 일 이다. Git 은 변경된 파일을 

Blob 개체로 저 장하고 현 Index 에 따라서 Tree 개체를 만 든다. 그리고 이전 커밋 개체와 최상위 Tree 
개체를 참 고해서 커밋 개체를 만 든다. 즉 Blob, Tree, 커밋 개체가 Git 의 주요 개 체이고 이 개체는 전부 
.git/objects 디랙 토리에 저장 된다. 이 예 제에서 생성한 개체는 아래와 같다: 



$ find .git/objects -type f 

.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2 
. git/obj ects/1 a/41 0ef bd1 3591 db07496601 ebc7a059dd55cf e9 # c 이 umit 3 
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2 
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41 b0e614 # tree 3 
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1 
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # a>mmit 2 
t git/objects/d6/70460b4b4aece5915caf5c68cl12f560a9fe3e4 # 'test content 
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.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1 
. git/obj ects/fa/49b077972391 ad58037050f2a75f74e3671 e92 # new . txt 
. git/obj ects/f d/f 4f c3344e67ab068f 836878b6c4951 e3b1 5f 3d # commit 1 



내부의 포 인터를 따 라가면 그림 9-3 과 같은 그 래프가 그려 진다. 



bak 



lo4iee 
third commit 




3c4e9c 

tree 












cocdca 

second commit 




dlSSeb 

tree 












fdf4fc 
first commit 




d8329f 

tree 





"version 2" I 

세 I 



fo49b0 

"new file" 



\6iboat 

■ test. txt ~ ► "version 1 ' 



그림 9.3： Git 저장소 내의 모든 개체 



9.2.3 개체 저장소 

내용 과함께 해 더도저 장한다 고얘기 했다. 잠시 Git 이 개체를 어떻게 저 장하는 지부터 살펴 보자. "what 
is up， doc?" 이 라는문 자열을 가지고 대화형 Ruby 쉘 irb 명령어 로흉내 내 보차: 



$ irb 

» content = "what is up, doc? 
=> "what is up, doc?" 



Git 은 개체의 타입을 시 작으로 헤더를 만 든다. 그 다음에 공백 문자 하나, 내용의 크기， 마 지막에 널 문 
자 를추가 한다: 



» header = "blob #{content.length}\0 
=> "blob 16\000" 



Git 은해더 와원래 내용을 합처서 SHA-1 체크심 을계산 한다. Ruby 에서도 require 로 SHA1 라이브 
러리 를가져 다가흥 내낼수 있다. require 로 라 이브러 리를포 함하고 나서 Digest: :SHA1 .hexdigest( ) 를 
호출 한다: 
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» store = header + content 
=> "blob 16\000what is up, doc?" 
» require 'digest/shal ' 
=> true 

» shal = Digest: :SHA1 .hexdigest(store) 

=> " bd9dbf5aae1 a3862dd1 526723246b20206e5fc37 " 



Git 은또 zlib 으 로내용 을압축 한다. Ruby 에도 zlib 라이브 러리가 있으니 Ruby 에서 도할수 있다. 라 

이브러 리를포 함하고 Zlib::Deflate.deflate() 를호출 한다: 

» require 'zlib' 
=> true 

» zlib_content = Zlib: ： Deflate. deflate (store) 

=> "x\234K\312\311OR04c(\317H,Q\310,V(-\320QH\311O\266\a\000_\034\a\235" 



마지 막으로 Zlib 으로 압축한 내용을 개체로 저장 한다. SHA—1 값 중에서 맨 앞에 있는 두 자를 가겨 

다하위 디 텍토리 이름 으로사 용하고 나머지 38 자 를그디 텍토리 안에 있 는파일 이름으 로사용 한다. 
Ruby 에서는 FileUtils. m kdir_p() 로하위 디텍 토리의 존 재를보 장하고 나서 File.openO 으로 파일을 
연다. 그리고 그 파일에 zlib 으로 압축한 내용을 write( ) 함수로 저장 한다. 

» path = ' .git/objects/' + sha1[0,2] + ■/■ + sha1[2,38] 
=> " . git/obj ects/bd/9dbf5aae1 a3862dd1 526723246b20206e5fc37 " 
» require 'fileutils' 
=> true 

» FileUtils . mkdir_p( File . dirname(path) ) 
=> " .git/objects/bd" 

» File.open(path, V) { If I f .write zlib_content } 

=> 32 

다 됐다. 이제 Git Blob 개체를 손으로 만들 었다. Git 개체는 모두 이 방 식으로 저 장하며 단지 종류만 
다 르다. 해더가 blob 이 아니 라그낭 commit 이나 tree 로시 작하게 되 는것뿐 이다. Blob 개체는 여기서 보 

여준 것과 거의 같지만 커밋이 개체나 Tree 개체는 각기 다른 형식 을사용 한다. 

9.3 Git 레 퍼런스 

git log 1a410e 라 고실행 하면견 체히스 토리를 볼수있 지만, 여견히 1a410e 를기억 해야 한다. 이커 
밋은 마지막 커 밋이기 때문에 히스 토리를 따라 모든 개체를 조회할 수 있다. SHA-1 값을 날로 사용하 
기보다 쉬운 이 름으로 된 포 인터가 있으면 그걸 사용 하는게 더 좋다. 외우기 쉬운 이 름으로 된 파일에 
SHA-1 값을 저장한 다. 

Git 에서 는이런 것을 "레퍼 런스" 또는 "refs" 라고부 른다. SHA—1 값이든 파일은 .git/refs 디 텍토리 
에 있다. 이 프로 젝트에 는아직 레퍼 런스가 하나도 없다. 이 디텍 토리의 구조는 매우 단순 하다: 
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$ find .git/refs 

.git/refs 

.git/refs/heads 

.git/refs/tags 

$ find .git/refs -type 

$ 




레퍼 런스가 있으면 마지막 커밋이 무 엇인지 기 억하기 쉽다. 사실 내 부는아 래처럼 단순 하다: 



$ echo " 1 a41 Oef bd1 3591 db074966O1 ebc7a059dd55cf e9" > .git/ref s/heads/master 



SHA-1 값 대신에 지금 만든 레퍼 런스를 사용할 수 있다: 



$ git log — pretty=oneline master 
1 a41 0ef bd1 3591 db07496601 ebc7a059dd55cf e9 third commit 
Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
f df 4f c3344e67ab068f 836878b6c4951 e3b1 5f 3d first commit 



레 퍼런스 파일을 직집 고치는 것이 좀 못마땅 하다. Git 에는 좀 더 안 전하게 바꿀 수 있는 update-ref 명 
렁이 있다: 



$ git update— ref refs/heads/master 1 a41 Oef bd1 3591 db07496601 ebc7a059dd55cf e9 



Git 브 랜치의 역할이 바로이 거다. 브탠치 는어떤 작업들 중마지 막작업 을가리 키는포 인터또 는레퍼 
런스이 다. 간단히 두 번째 커밋을 가 리키는 브 탠치를 만들어 보차: 



$ git update— ref refs/heads/test cacOca 




브 랜치는 직집 가 리키는 커밋과 그 커 밋으로 따라갈 수 있는 모든 커밋을 포함 한다: 

$ git log — pretty=oneline test 

Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
f df 4f c3344e67ab068f 836878b6c4951 e3b1 5f 3d first commit 



이제 Git 데이터 베이스 는그림 9-4 처럼 보 인다. 

git branch (branchname) 명 렁을실 행하면 Git 은내부 격으로 update-ref 명렁 을실행 한다. 입력 받은브 
탠치 이름과 현 브 탠치의 마지막 커밋의 SHA-1 값을 가겨다 update-ref 명령을 실행 한다. 
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io4i«e 






refs/heads/master 




third commit 




traa 









If 7o7o 1 

"version 2" 















r«rs/he»ds/te*t 




second commit 



1*^ L- 1 

tTM 
_ __h. 



fdf4ft 






first commit 




tree 



lUbooc 
.txt ~ ^1 "version 1 



그림 9.4: 브랜치 레퍼 런스가 추가된 Git 데이터 베이스 



9.3.1 HEAD 

git branch (branchname) 명령을 실행할 때 Git 은 어떻게 마지막 커밋의 SHA—1 값을 아는 걸까? 
HEAD 파일 은현브 랜치를 가리키 는간접 (symbolic) 레퍼런 스다. 간접 레퍼런 스이기 때문에 다른레 
퍼런 스와다 르다. 이 레퍼 런스은 다른레 퍼런스 를가리 키는것 이라서 SHA-1 값이 없다. 파일 을열어 
보면 아래와 같이생 겼다: 



$ cat .git/HEAD 

ref ： refs/heads/master 



git checkout test 를실 행하면 Git 은 HEAD 파일을 아래와 같이바 꾼다: 



$ cat .git/HEAD 
ref: refs/heads/test 



git commit 을실 행하면 커밋개 체가만 들어지 는데， 지금 HEAD 가 가리키 고있던 커밋의 SHA-1 값이 
그커밋 개체의 부모 로사용 된다. 

이 파일도 손으로 직집 편집할 수 있지만 symbolic-ref 라는 명 렁어가 있어서 좀 더 안 전하게 사용할 수 
있다. 이 명 렁으로 HEAD 의 값을 읽을수 있다: 



$ git symbolic— ref HEAD 
refs/heads/master 



HEAD 의값 을변경 할수도 있다: 



$ git symbolic— ref HEAD refs/heads/test 
$ cat .git/HEAD 
ref: refs/heads/test 



refs 형식에 맞지 않으면 수정할 수 없다: 
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$ git symbolic-ref HEAD test 

fatal ： Refusing to point HEAD outside of refs/ 



9.3.2 태그 

중요한 개체는 모두 살 펴봤고 남은 개체가 하나 있다. 태그 개체는 커밋 개체랑 매우 비숫 하다. 커밋 개 
체처럼 누가, 언제 태그를 달 았는지 태그 메시 지는무 엇이고 어떤 커밋을 가리키 는지에 대한정 보가포 

함 된다. 태그 개체는 Tree 개체가 아니라 커밋 개체를 가 리키는 것이 그들의 차 이다. 브탠 치처럼 커밋 
개 체를가 리키지 만옮길 수는 없다. 태그 개체 는늘그 이름이 뜻하는 커밋 만가리 킨다. 
2 장에서 배 웠듯이 태그는 Annotated 태그와 Lightweight 태그 두 종류로 나 뉜다. 먼저 아래와 같이 
Lightweight 태그를 만들어 보자: 

$ git update— ref refs/tags/v1 .0 Cac0cab538b970a37ea1e769cbbde608743bc96d 



Lightwieght 태그는 만들기 쉽다. 브 탠치랑 비숫 하지만 브탠 치처럼 옮길 수는 없다. 이에 비해 
Annotated 태그는 좀 더 복잡 하다. Annotated 태그를 만들면 Git 은 태그 개체를 만들고 거기에 커밋 
을 가 리키는 레퍼 런스를 저장 한다. Annotated 태그는 커밋을 직접 가 리키지 않고 태그 개체를 가리킨 
다. -a 옵션을 주고 Annotated 태그를 만들고 확인해 보자: 

$ git tag -a v1 .1 1 a41 Oef bd1 3591 db07496601 ebc7a059dd55cf e9 -m 'test tag' 



태그 개체의 SHA-1 값 을확인 한다: 

$ cat ,git/refs/tags/v1 .1 

95851 91 f37f7b0fb9444f35a9bf50de1 91 beadc2 



cat-file 명 령으로 해당 SHA—1 값의 내용을 조회 한다: 

$ git cat-file -p 95851 91 f 37f 7b0f b9444f 35a9bf 50de1 91 beadc2 
obj ect 1 a41 0efbd1 3591 db07496601 ebc7a059dd55cfe9 
type commit 
tag v1 . 1 

tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 -0700 
test tag 

object 부분에 있는 SHA-1 값이 실제로 태그가 가 리키는 커밋 이다. 커밋 개 체뿐만 아니라 모든 Git 개 
체에 태그를 달 수 있다. 커밋 개체에 태그를 다는 것이 아니라 Git 개체에 태그를 다는 것 이다. Git 을 개 
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발하는 프 로젝트 에서는 관 리자가 자신의 GPG 공 개키를 Blob 개체로 추 가하고 그 파일에 태그를 달았 
다. 다음명 렁으로 그공개 키를확 인할수 있다: 



$ git cat-file blob junio— gpg— p 니 b 



Linux Kernel 저장 소에도 커밋이 아닌 다른 개체를 가 리키는 태그 개체가 있다. 그 태그는 저 장소에 
처 음으로 소스 코드를 임포 트했을 때 그 첫 Tree 개체를 가리 킨다ᅳ 

9.3.3 리 모트레 퍼런스 

리모트 레퍼런 스라는 것도 있다. 리 모트를 추 가하고 Push 하면 Git 은 각 브탠 치마다 Push 한 마지막 커 
밋이 무 엇인지 refs/remotes 디롁 토리에 저장 한다. 예를 들어， origin 이라는 리모 트를추 가하고 master 
브 탠치를 Push 한다: 

$ git remote add origin git@github . com ： schacon/simplegit-progit . git 
$ git push origin master 
Counting objects: ^^ , done. 
Compressing objects: 100% (5/5), done. 
Writing objects: 100% (7/7), 716 bytes, done. 
Total 7 (delta 2), reused 4 (delta 1) 
To git@github . com : schacon/ simplegit-progit . git 
a11bef0. .ca82a6d master -> master 



origin 의 master 브탠 치에서 서버 와마지 막으로 교환한 커밋이 어떤 것인지 ref s/remotes/origin/ 
master 파일 에서확 인할수 있다: 

$ cat .git/refs/remotes/origin/master 
Ca82a6dff817ec66f44342007202690a93763949 

리모트 레퍼 런스는 Checkout 할 수 없다. refs/heads 에 있는 레퍼 런스인 브 탠치와 다 르다. 이 리모트 
레퍼 런스는 서버의 브탠 치가가 리키는 커밋이 무 엇인지 격어둔 일종의 북마크 이다. 

9.4 Packfile 

테 스트용 Git 저 장소의 개체 데 이터베 이스를 다시 살펴 보자. 지금 개체는 모두 1 1 개로 Blob 4 개, Tree 
3 개, 커밋 3 개, 태그 1 개가 있다: 

$ find .git/objects -type f 

.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2 
. git/objects/1 a/41 0ef bd1 3591 db07496601 ebc7a059dd55cf e9 # a^mmit 3 
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git/objects/1 f/7a7a472abf3dd9643fd61 5f6da379c4acb3e3a 




test.txt 


v2 


git/objects/3c/4e9cd789d88d8d89c1073707c3585e41 b0e614 


# 


tree 3 




git/objects/83/baae61804e65cc73a7201a7252750c76066a30 




test.txt 


v1 


git/objects/95/85191f37f7b0fb9444f35a9bf50de191beadc2 


# 


tag 




git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d 


# 


commit 2 




git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 


# 


'test content 1 


git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 


# 


tree 1 




git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 




new.txt 




git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d 


# 


commit 1 





Git 은 zlib 으 로파일 내 용을압 축하기 때문에 저장 공간이 많이 필 요하지 않다. 그래서 이 데이 터베이 
스에 저장된 파일은 겨우 925 바이 트밖에 되지 않 는다. 크기 가큰파 일을추 가해서 이 기능의 효 과를좀 
더 살펴 보자. 앞 장에서 사 용했던 Grit 라이브 러리에 들어 있는 repo.rb 파일을 추가 한다. 이 파일의 크 
기는약 12K 이다. 

$ curl — L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb 

$ git add repo.rb 

$ git commit -m 'added repo.rb' 

[master 484a592] added repo.rb 

3 files changed, 459 insertions(+), 2 deletions(-) 

delete mode 1 00644 bak/test.txt 

create mode 1 00644 repo.rb 

rewrite test.txt (100%) 



추가한 Tree 개체 를보면 repo.rb 파일의 SHA-1 값이 무 엇인지 확 인할수 있다: 



$ git cat-file -p master A {tree} 




100644 blob f a49b077972391 ad58037050f 2a75f 74e3671 e92 


new.txt 


100644 blob 9bc1 dc421 dcd51 b4ac296e3e5b6e2a99cf 44391 e 


repo . rb 


100644 blob e3f094f522629ae358806b17daf78246c27c007b 


test.txt 


개체의 크기는 아래와 같이 확인 한다: 



$ du -b . git/obj ects/9b/d dc421 dcd51 b4ac296e3e5b6e2a99cf 44391 e 
41 02 . git/obj ects/9b/ddc421 dcd51 b4ac296e3e5b6e2a99cf44391 e 



파일을 수 정하면 어떻게 되는지 살펴 보자: 
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$ echo ■# testing' » repo . rb 




$ git commit —am 'modified repo a bit 1 




[master ablafef J modified repo a bit 




1 files changed, 1 insertions(+) f 0 deletions(-) 




수^ 하 케] j 이 Tree 개체름 화 이하며 흐 미로우 S 음 발겨함 


수? J 다: 


$ git cat-file -p master A {tree} 




100644 blob f a49b077972391 ad58037050f 2a75f 74e3671 e92 


new.txt 


100644 blob 05408d195263d853f09dca71d55116663690c27c 


repo . rb 


100644 blob e3f094f522629ae358806b17daf78246c27c007b 


test.txt 



이 Blob 개체는 다른개 체다. 새 Blob 개체는 400 줄이 후에한 줄을더 추가한 새개체 이다. Git 은완 
견히 새로운 Blob 개체를 만들어 저장 한다: 



$ du -b . git/obj ects/05/408d1 95263d853f 09dca71 d551 1 6663690c27c 
41 09 . git/obj ects/05/408d1 95263d853f09dca71 d5511 6663690c27c 

그럼 약 4K 짜리 파일을 두 개 가지게 된다. 거의 같은 파일을 두 개나 가지게 되는 것이 못 마땅할 수도 
있다. 처음 것과 두 번째것 사이의 차 이점만 저장할 수 없 을까? 

가능 하다. Git 이 처음 개체를 저 장하는 형식은 Loose 개체 포멧 이라고 부 른다. 하지만 나중에 이 개체 
를 파일 하나로 압축 (Pack) 할 수 있다. 그래서 공간을 결 약하고 효율을 높일 수 있다. Git 이 이렇게 압 
축하는 때는 Loose 개체가 너무 많 거나, git gc 명령을 실 행했을 때， 그리고 리모트 서버로 Push 할 때 
압축 한다. git gc 명 렁을실 행해서 어떻게 압축 하는지 살펴 보자: 

$ git gc 

Counting objects: M , done. 
Delta compression using 2 threads. 
Compressing objects: 100% (13/13), done. 
Writing objects: 100% (17/17), done. 
Total 17 (delta 1), reused 10 (delta 0) 



objects 디롁 토리를 열 어보면 개체 대 부분이 사 라겼고 한 쌍의 파일이 새로 생 겼다: 

$ find .git/objects -type f 

. git/obj ects/71 /08f7ecb345ee9d00841 93f1 47cdad4d2998293 
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 
. git/obj ects/info/packs 
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9.4 절 Packfile 



. git/objects/pack/pack— 7a1 6e4488ae40c7d2bc56ea2bd43e25212a66c45 . idx 
. git/objects/pack/pack— 7a1 6e4488ae40c7d2bc56ea2bd43e2521 2a66c45 . pack 




압 축되지 않은 Blob 개체 는어떤 커밋도 가 리키지 않는 개체 다. 즉, "what is up, doc?" 과 "test 

content" 예 제에서 만 들었던 개체 이다. 어떤 커 밋에도 추가돼 있지 않으면 이 개체는 dangling 개체로 

취 급되고 Packfile 에 추 가되지 않 는다. 

새 로생긴 파일은 Packfile 과그 Index 이다. 파일 시스 템에서 삭제된 개체 가전부 이 Packfile 에 저장 
된다. Index 파일은 빠르게 찾을수 있도록 Packfile 의 오 프셋이 들어 있다. git gc 명 령을실 행하기 전 
에 있던 파일 크기는 약 8K 정도였 었는데 새로 만 들어진 Packfile 은 겨우 4K 에 불고 h 하다. 짱 이다. 개체 
를 압 축하면 디스크 사 용량은 질 반으로 줄 었다. 

어떻게 이런 일이 가능 할까? 개 체를압 축하면 Git 은먼저 이름 이나크 기가비 슷한파 일을찾 는다. 그리 
고 두 파일을 비 교해서 한 파일은 다른 부분만 겨장 한다. Git 이 얼마나 공간을 절약해 주는지 Packfile 

을 열어 확인할 수 있다. git verify-pack 명 렁어는 압축한 내용을 보여 준다: 



$ git verify-pack -v \ 

.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.idx 



01 55eb4229851 634a0f 03eb265b69f 5a2d56f 341 


tree 


71 


76 5400 


05408d1 95263d853f09dca71d551 1 6663690c27c 


blob 


12908 3478 874 


09f01 cea547666f58d6a8d809583841 a7c6f01 30 


tree 


106 


107 


5086 


1 a41 0efbd1 3591 db07496601 ebc7a059dd55cfe9 


commit 


225 


151 


322 


1 f7a7a472abf3dd9643fd61 5f6da379c4acb3e3a 


blob 


10 


19 5381 


3c4e9cd789d88d8d89c1073707c3585e41 b0e61 4 


tree 


101 


105 


5211 


484a59275031 909e1 9aadb7c9226271 9cfcdf1 9a 


commit 


226 


153 


169 


83baae61804e65cc73a7201a7252750c76066a30 


blob 


10 


19 5362 


95851 91 f37f7b0fb9444f35a9bf50de1 91 beadc2 


tag 


136 


127 


5476 


9bc1dc421 dcd51 b4ac296e3e5b6e2a99cf44391 e 


blob 


7 18 5193 1 \ 


05408d1 95263d853f09dca71 d5511 6663690c27c 








ab1 afef80fac8e34258ff41 fc 1 b867c702daa24b 


commit 


232 


157 


12 


Cac0cab538b970a37ea1e769cbbde608743bc96d 


commit 


226 


154 


473 


d8329fc1cc938780ffdd9f94e0d364e0ea74f579 


tree 


36 ■ 


46 5316 


e3f094f522629ae358806b17daf78246c27c007b 


blob 


1486 734 4352 


f8f51d7d8a1760462eca26eebafde32087499533 


tree 


106 


107 


749 


fa49b077972391ad58037050f2a75f74e3671e92 


blob 


9 18 856 


fdf4fc3344e67ab068f836878b6c4951 e3b1 5f3d 


commit 


177 


122 


627 



chain length =1:1 object 

Pack-7a16e4488ae40c7d2bc56ea2bd43e2521 2a66c45 . pack ： ok 



9bc1d Blob 이 처음 추가한 repo.rb 파일 인데， 이 Blob 은 두번째 버견인 05408 Blob 을가리 킨다. 개체 
에서 세 번째 컬럼은 압축된 개체의 크기를 나타 낸다. 05408 의 크기는 1 2K 지만 9bc1d 는 7 바이 트밖에 안 
된다. 특이한 점은 원본을 그대로 저 장하는 것이 첫 번째가 아니라 두 번째 버전 이라는 것 이다. 첫 번째 
버전은 차 이점만 저장 된다. 최신 버전에 집근할 때가 더 많고 그래서 속도가 더 빨라야 하기 때문에 이 
렇게 한다. 
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언제나 다시 압축할 수 있기 때문에 이 기능은 정말 판 타스틱 하다. Git 은 자 동으로 데 이터베 이스를 재 
압 축해서 공간을 결약 한다. 그리고 git gc 명 렁으로 직집 다시 압축할 수도 있다. 

9.5 Refspec 

이 책에서 리모트 브 탠치가 어떻게 로컬 레퍼 런스로 연 결하는 것인지 간 단하게 배 웠지만 실 제로는 좀 
더 복잡 하다. 아 래처럼 리 모트겨 장소를 추가해 보자: 



$ git remote add origin git@github . com ： schacon/simplegit-progit . git 



이 명렁은 origin 이라는 저장소 이름， 그 URL， Fetch 할 Ref spec 를 .git/config 파일에 추가 한다: 

[remote "origin" ] 

url = git@github . com ： schacon/simplegit-progit . git 
fetch = +refs/heads/*:refs/remotes/origin/^ 

Refspec 형식은 +와<^〔>： <dest〉 로돼 있다. 누는생 락가능 하고， <^〔>은 리 모트저 장소의 레퍼 런스고 
어었>는 매핑되 는로컬 저 장소의 레 퍼런스 이다. + 가 없으면 Fast—forward 가아 니라도 업 데이트 된다. 

git remote add 명령은 알아서 생 성한설 정대로 서버의 refs/heads/ 에 있 는레퍼 런스를 가져다 로걸의 
refs/remotes/origin/ 에 만 든다. 로 컬에서 서버에 있는 master 브 랜치에 집 근할때 는아래 와같이 한다: 



$ git log origin/master 

$ git log remotes/origin/master 

$ git log ref s/remotes/origin/master 




이 세 개를 모두 같다. Git 은 모두 ref s/remotes/origin/master 라고 해석 한다. 

master 브 랜치만 가져을 수 있게 하려면 fetch 부분을 아래와 같이 바꿔 준다. 그러면 다른 브 탠치는 가 
져올수 없다: 



fetch = +refs/heads/master: ref s/remotes/origin/master 



이것은 해당 리모트 저장 소에서 git fetch 명렁을 실행할 때 자 동으로 사 용되는 Refspec 이다. 다른 
Refspec 이 필 요하면 그 낭아규 먼트로 넘 긴다. 리모트 브랜치 master 를로컬 브탠치 origin/mymaster 로 
가겨오 려면아 래와같 이실행 한다. 



$ git fetch origin master: ref s/remotes/origin/mymaster 




Refspec 을 여러개 님겨도 된다. 한 끼번에 브 탠치를 여러개 가겨 온다: 
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9.5 절 Refspec 



$ git fetch origin master :refs/remotes/origin/mymaster \ 

topic ： refs/remotes/origin/ topic 
From git@github.com： schacon/simplegit 

！ [rejected] master -> origin/mymaster (non fast forward) 

* [new branch] topic -> origin/topic 



여기서 master 브 탠치는 Fast—forward 가아 니라서 거절 된다. 하 지만， Refspec 앞에 + 를추 가하면 강 
제 로덮어 쓴다. 

설정 파 일에도 Refspec 을여러 개 적을 수 있다. master 와 experiment 브 탠치를 둘다 적으면 항상 함께 
가겨 온다: 

[remote "origin" ] 

url = git@github . com ： schacon/simplegit-progit . git 

fetch = +refs/heads/master:refs/remotes/origin/master 

fetch = +refs/heads/experiment:ref s/remotes/origin/experiment 



하 지만, Glob 패 턴은사 용할수 없다: 

fetch = +refs/heads/qa*:ref s/remotes/origin/qa* 



그 대신 네임스 페이스 형식 으로는 사용할 수 있다. 만약 QA 팀이 Push 하는 브 탠치가 있고 이 브탠치 
를 가 져오고 싶으면 아래와 같이 설정 한다. 다음은 master 브 탠치와 QA 팀의 브 탠치만 가 져오는 설정 
이다: 

[remote "origin" ] 

url = git@github . com ： schacon/simplegit-progit . git 
fetch = +refs/heads/master:refs/remotes/origin/master 
fetch = +refs/heads/qa/*:ref s/remotes/origin/qa/* 



좀 더 복잡한 것도 가능 하다. QA 팀뿐만 아 니라, 일반 개 발자, 통합 팀 등이 사 용하는 브 랜치를 네임스 
페이스 별로 구분해 놓으면 좀 더 Git 을 편 리하게 사용할 수 있다. 

9.5.1 Refspec Push 하기 

네임스 페이스 별로 가 져오는 방법은 매우 편리 하다. 하지만 Push 할 땐 어 떨까? QA 팀이 qa/ 네임스 

페 이스에 자신의 브 탠치를 Push 할 때도 Refspec 을 사용할 수 있 을까? 

QA 팀은 master 브 탠치를 리모트 저 장소에 qa/master 로 Push 할 수 있다: 
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$ git push origin master :refs/heads/qa/master 



git push origin 을 실행할 때마다 Git 이 자 동으로 Push 하게 하려면 아래 와같이 설정 파일에 push 항 
목 을추가 한다: 

[remote "origin" ] 

url = git@github . com ： schacon/simplegit-progit . git 
fetch = +refs/heads/*:refs/remotes/origin/^ 
push = refs/heads/master:refs/heads/qa/master 




다시 말 하지만 git push origin 을 실 행하면 로컬 브탠치 master 를 리모트 브탠치 qa/master 로 Push 한 
다, 



9.5.2 레퍼 런스삭 제하기 

Refspec 으로 서버에 있는 레퍼 런스를 삭제할 수 있다: 



$ git push origin ： topic 




Refspec 의 형식은 <src〉:<dst〉 이니까 <src>i 비우고 실 행하면 <dst> 를 비 우라는 명령이 된다. 그래 
서<반0 는삭제 된다. 



9.6 데이터 전송프 로토콜 

Git 에서 데 이터를 견송할 때 보통 두 가지 종류의 프로 토콜을 사용 한다. 하나는 HTTP 프로토 콜이고 
다른 종류는 스 0 1 트 프 로토콜 0 ᅵ다. f ile ： //, ssh ： //， and git ： // 프 로토콜 0 ᅵ 스0 K 트 프 로토콜 0 ᅵ 다. 주 
로 사 용하는 두 종류 프로 토콜을 통해 Git 이 어떻게 데 이터를 견송 하는지 살펴 본다. 

9.6.1 Dumb 프 로토콜 

Git 에서는 HTTP 프로 토클을 Dumb 프 로토콜 이라고 부 른다. 서버가 데 이터를 전송할 때 Git 에 최적 
화된 코드를 견혀 사 용하지 않 는다. Fetch 과정은 GET 요청을 여러개 보내는 과정 이다. 서버의 Git 저 
장소 레이 아웃은 특 별하지 않다고 가정 한다. simplegit 라이브 러리에 대한 http-fetch 과정을 살펴보 
자: 



$ git clone http ： //github . com/schacon/simplegit-progit . git 



처 음에는 info/refs 파일을 내려받 는다. 이 파일은 update- server- info 명 령으로 작 성되기 때문에 
post-receive 흑에서 update-server-inf o 명렁을 호출해 줘야만 HTTP 를 사용할 수 있다. 
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9.6 절 데이 터견송 11 ？ 두쿨 


=> GET info/refs 

Ca82a6dff817ec66f44342007202690a93763949 


refs/heads/master 





리모 트레퍼 런스와 SHA 값 이든목 록을가 져왔고 다음은 HEAD 레퍼런 스를찾 는다. 이 HEAD 레퍼 
런스 덕택에 데 이터를 내 려받고 나서 어떤 레퍼 런스를 Checkout 할지 알게 된다: 



=> GET HEAD 

ref: refs/heads/master 



그래서 나중에 데이터 견송을 마치면 master 브 탠치를 Checkout 해야 한다. 지금 은아직 견송 을시작 
하는 시점 이다. info/refs 에 ca82a6 커 밋에서 시 작해야 한다고 나와 있다. 그래서 그 커밋을 기 점으로 

Fetch 한다: 



=> GET Objects/ca/82a6dff817ec66f44342007202690a93763949 
(179 bytes of binary data) 




서버에 Loose 포맷 으로돼 있기 때문에 HTTP 서 버에서 정격 파일 을가져 오듯이 개 체를가 져오면 된 
다. 이렇게 서버 로부터 얻어온 개체를 Z |ib 로 압축을 풀고 header 를 떼어 내면 아래와 같은 모습이 된 
다: 

$ git cat-file -p Ca82a6dff817ec66f44342007202690a93763949 

tree cfda3bf379e4f8dba871 7dee55aab78aef7f4daf 

parent 085bb3bcb608e1 e8451 d4b2432f8ecbe6306e7e7 

author Scott Chacon <schacon@gmail.com> 1205815931 -0700 

committer Scott Chacon 〈schacon@gmail.com〉 1240030591 -0700 

changed the version number 

아직 개체를 두 개 더 내려 받아야 한다. cfdasb 개체는 방금 내 려받은 커밋의 Tree 개체 이고, ossbbs 개 
체는 부모커 밋개체 이다: 

=> GET objects/08/5bb3bcb608e1 e8451 d4b2432f8ecbe6306e7e7 
(179 bytes of data) 



커밋 개체는 내려받 았다. 하 지만， Tree 개체를 내려받 으려고 하면: 
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=> GET 0bjects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf 
(404 - Not Found) 



이런! 존 재하지 않 는다는 404 메 시지가 뜬다. 해당 Tree 개체가 서버에 Loose 포 맷으로 겨장돼 있 
지 않을 수 있다. 해당 개체가 다른 저 장소에 있거나 저 장소의 Packfile 속에 들어 있을 때 그 렇다. 우선 
Git 은 다른 저장소 목 록에서 찾 는다: 

=> GET objects/info/http-alternates 
(empty file) 

다른 저장소 목록에 없으면 Git 은 Packfile 에서 해당 개체를 찾 는다. 그래서 프로 젝트를 Fork 해도 디 
스크 공간을 효율 적으로 사용할 수 있다. 우선 서 버에서 받은 다른 저장소 목 록에는 없기 때문에 개체는 
확실히 Packfile 속에 있다. 어떤 Packfile 이 있 는지는 objects/info/packs 파일에 들어 있다. 이 파일 

도 update-server-info 명렁이 생성 한다. 
=> GET objects/info/packs 

P pack— 81 6a9b2334da9953e530f27bcac22082a9f5b835 . pack 



서 버에는 Packfile 이 하나 있다. 개체는 이 파일 속에 있다. 이 개체가 있는지 Packfile 의 ln- 
dex(Packfile 이 포 함하는 파일의 목록) 에서 찾 는다. 서버에 Packfile 이 여러 개 있으면 이런 식으 
로 개체가 어떤 Packfile 에 있는지 찾 는다: 

=> GET objects/pack/pack-81 6a9b2334da9953e53Of27bcac22082a9f5b835 . idx 
(4k of binary data) 



이제 Packfile 의 Index 를 가 겨와서 개체가 있는지 확인 한다. Packfile Index 에서 해당 개체의 SHA 
값과 오 프셋을 파악 한다. 개체를 찾 았으면 해당 Packfile 을 내려받 는다: 

=> GET objects/pack/pack-81 6a9b2334da9953e530f27bcac22082a9f5b835 . pack 
(13k of binary data) 



Tree 개체를 얻어 오고 나면 커밋 데 이터를 가겨 온다. 아마도 방금 내 려받은 Packfile 속에 모든 커밋 
데이터 가들어 있을것 이다. 서버에 다시 견송 요청을 보내지 않 는다. 다 끝나면 Git 은 HEAD 가 가리키 
는 master 브 랜치의 소스 코드를 복 원해놓 는다. 

이 과 정에서 출 력하는 것을 한 번에 모아 보면 아래와 같다: 
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$ git clone http://gith 니 b.a>m/schacm/simplegit—p^^ 

Initialized empty Git repository in / private/tmp/ simplegit-progit/ . git/ 

got ca82a6dff81 7ec66f44342007202690a93763949 

walk Ca82a6dff817ec66f44342007202690a93763949 

got 085bb3bcb608e1 e8451 d4b2432f8ecbe6306e7e7 

Getting alternates list for http://github.com/schacon/simplegit-progit.git 
Getting pack list for http://github.com/schacon/simplegit-progit.git 
Getting index for pack 816a9b2334da9953e530f27bcac22082a9f 5b835 
Getting pack 816a9b2334da9953e530f27bcac22082a9f5b835 
which contains Cfda3bf379e4f8dba8717dee55aab78aef7f4daf 
walk 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 
walk a1 1 bef 06a3f 659402f e7563abf 99ad00de2209e6 



9.6.2 스 마트프 로토콜 

HTTP 프로 토클은 매우 단순 하다는 장점이 있으나 효을 격으로 전 송하지 못 한다. 스마트 프로 토클로 
데 이터를 전송하 는것이 더 일반적 이다. 이 프로토 콜은리 모트서 버에서 처리하 는일이 있다. 서 버는클 
라 이언트 가어떤 데이터 를갗고 있고어 떤데이 터가필 요한지 분석 하여실 제로견 송할데 이터를 추려낸 
다. 데 이터를 업 로드할 때 하는 일과 다운 로드할 때 하는 일이 다 르다. 



데이터 업로드 

리모트 서버로 데 이터를 업로 드하는 과정은 send-pack 과 receive—pack 과 정으로 나눌 수 있다. 클라이 
언 트에서 실 행되는 send-pack 과서 버의 receive—pack 은서로 연결 된다ᅳ 

originURL 이 SSHURL 인상 태에서 git push origin master 명 렁을실 행하면 Git 은 send-pack 을시작 
한다. 이 과정 에서는 SSH 연결을 만들고 이 SSH 연결을 통해서 다음과 같은 명 렁어를 실행 한다: 



$ ssh -x git@github.com "git— receive— pack ' schacon/ simplegit-progit . git "' 
005bca82a6dff817ec66f4437202690a93763949 ref s/heads/master report-status delete— refs 
003e085bb3bcb608e1 e84b2432f8ecbe6306e7e7 ref s/heads/topic 
0000 




git-receive-pack 명렁은 레 퍼런스 정보를 한줄에 하나씩 보여 준다. 첫 번째 줄에는 master 브랜치 
의 이름과 SHA 체크섬 을보여 주는데 여기에 서버의 Capability 도함깨 보 여준다 (여 기서는 report- 
status 오 (• delete— ref sO | 디 ■) . 

각줄의 처음은 4 바이트 는뒤어 이 어지는 나머지 데 이터의 길이 를나타 낸다. 첫줄을 보자. 005b 로시 
작 하는데 1 0 진수로 91 을나타 낸다. 첫 줄의 처음 4 바 이트를 제외한 나머지 길이가 91 바이 트라는 뜻 
이다. 다음줄 의값은 003b 이 고이는 62 바이트 를나타 낸다. 마 지막줄 은값은 0000 이다. 이 는서버 
가 레 퍼런스 목록의 출력을 끝 냈다는 것을 의미 한다. 

서버에 뭐가 있는지 알기 때문에 이제 서버에 없는 커밋이 무 엇인지 알 수 있다. Push 할 레퍼 런스에 대 

한 정보는 send—pack 과 정에서 서버의 receive—pack 과 정으로 전달 된다. 예를 들어 master 브 랜치를 업 
데이 트하고 experiment 브 랜치를 추가할 때는 아래와 같은 정보를 서버에 보 낸다: 
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0085ca82a6dff817ec66f44342007202690a93763949 


1 5027957951 b64cf874c3557a0f 3547bd83b3ff6 


refs/ 


heads/master report-status 








Cdfdb42577e2506715f8cfeacdbabc092bf63e8d 


refs/ 


heads/experiment 






0000 







SHA-1 값이 모두' 0' 인 것 은없음 (*) 을의미 한다. experiment 레퍼런 스는새 로추가 하는것 이라서 
왼쪽 SHA— 1 값이 모두 0 이다. 반대로 오른쪽 SHA—1 값이 모두' 0' 이면 레퍼런 스를삭 제한다 는의미 
다. 

Git 은예견 SHA ，새 SHA, 레퍼런 스이름 을한줄 한줄에 담 아견송 한다. 첫줄에 는클라 이언트 
Capability 도포함 된다. 그 다음에 서버에 없 는객체 를견부 하나의 Packfile 에 담 아전송 한다. 마지막 
에 서버는 성공 했거나 실패 했다고 응답 한다: 



000Aunpack ok 



데이터 다 운로드 

데 이터를 다운로 드하는 것는 f etc h-p ac k 과 upload-pack 과 정으로 나 뉜다. 클라이 언트가 fetch-pack 을 
시 작하면 서버의 upload-pack 에 연 결되고 서로 어떤 데 이터를 내려 받을지 결정 한다. 
리모트 저장 소에서 upload-pack 과정을 시 작하는 방법 은여러 가 지다. receive—pack 처럼 SSH 를 통하 
거나 포트가 9418 인 Git 데몬을 통해서 시작 할수도 있다. Git 데 몬을사 용하면 fetch-pack 은연 결되자 
마아래 와같은 데이터 를전송 한다: 



003f git-upload-pack schacon/simplegit-progit .git\Ohost=myserver.com\0 



처음 4 바이트 는뒤에 이어지 는데이 터의길 이다. 첫번째 NULL 바이트 까지가 실행할 명렁이 고다음 
NULL 바이트 까지는 서버의 호스트 이름 이다. Git 데돈은 명령이 실행 가능 한지, 저 장소가 존재하 는지, 
권한은 있는지 등을 확인 한다. 모든 것이 가 능하면 upload-pack 과정을 시 작하고 들 어오는 요청 데이터 
를처리 한다: 

SSH 프로 토콜을 사 용하면 fetch-pack 은 아래와 같이 실행 한다: 



$ ssh -x git@github.com "git-upload-pack ' schacon/simplegit-progit . git ' " 
내부 방 식이야 어 쨌든， fetch-pack 과 연결된 upload-pack 은 아래와 같은 데 이터를 전송 한다: 



0088ca82a6dff817ec66f44342007202690a93763949 HEAD\Omulti_ack thin-pack \ 

side-band side— band— 64k ofs— delta shallow no-progress include— tag 
003fca82a6dff81 7ec66f44342007202690a93763949 ref s/heads/master 
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003e085bb3bcb6O8e1 e8451 d4b2432f8ecbe6306e7e7 refs/heads/topic 
0000 

위 receive— pack 의 응답과 매우 비숫하 지만， Capability 부분은 다 르다. HEAD 레퍼 런스도 알 려주기 
때문에 저 장소를 Clone 하면 무엇을 Checkout 해야 할지 안다. 

fetch-pack 은 이 정보를 살 펴보고 이미 가지는 개체 에는 "have" 를 붙이고 내려 받아야 하는 개체는 
"want" 를붙인 정 보를만 든다. 마지 막줄에 "done" 이라고 적어서 보내면 서버의 upload-pack 은해당 
데 이터를 Packfile 로 만들어 전송 한다: 



0054want Ca82a6dff817ec66f44342007202690a93763949 of s— delta 

0032have 085bb3bcb608e1 e8451 d4b2432f8ecbe6306e7e7 

0000 

0009done 




아주기 본격인 상황인 데이터 전송 프로 토콜에 대해 살펴보 았다. m ulti_ack 나 side-band 같은 더 복잡한 
시나 리오도 있다. 하 지만， 여기 에서는 스마트 프 로토콜 과정을 알 수 있는 가장기 초격인 시나 리오를 설 
명 했다. 



9.7 운영 및데이 터복구 

언 젠가는 저 장소를 손수 정 리해야 할 날이 올지도 모 른다. 겨 장소를 좀 더 알차게 (Compact) 만 들고， 
다른 VCS 에서 임포 트하고 나서 그 간재를 치운다 든가, 아니면 문제가 생겨서 복 구해야 할 수도 있다. 
이결은 이럴때 필 요한것 을설명 한다. 



9.7.1 운영 

Git 은 때가 되면 자 동으로 "auto gc" 명령을 실행 한다. 물론 거의 실 행되지 않 는다. Loose 개체 
가 너무 많 거나， Packfile 자체가 너무 많으면 Git 은 그제야 진짜로 git gc 명령을 실행 한다. gc 명령 
은 Garbage 를 C 이 lect 하는 명렁 이다. 이 명령은 Loose 개체를 모아서 Packfile 에 저장 하거나 작은 
Packfile 을 모아서 하나의 큰 Packfile 에 저장 한다. 그리고 아무런 커밋도 가 리키지 않는 개체가 있고 
그 상태가 오 래가면 (a few months) 그때 개체를 삭제 한다. 
직 집자동 gc 명 렁을실 행할수 있다: 



$ git gc ―— auto 



이 명렁을 실 행해도 보통은 아무 일도 일 어나지 않 는다. Loose 개체가 7 천 개가 님거나 Packfile 이 50 

개 가넘지 않으면 Git 은 실제로 gc 명 렁을실 행하지 않 는다. 필 요하면 gc.auto 나 gc.autopacklimit 설정 
으 로그숫 자를조 결할수 있다: 

gc 는 레퍼 런스를 파일 하나로 압축 한다. 예를 들어 저 장소에 아래와 같은 브 랜치와 태그가 있다고 하자: 
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$ find .git/refs -type f 
. git/refs/heads/experiment 
.git/refs/heads/master 
.git/refs/tags/v1 .0 
.git/refs/tags/v1 .1 



git gc 를실 행하면 refs 에 있 는파일 은사라 진다. 대신 Git 은그 파일을 .git/packed-refs 파일 로압ᅩ 
해서효 율을높 인다: 



$ cat .git/packed-refs 
# pack— refs with: peeled 

Cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment 
ab1afef80fac8e34258ff41fdb867c702daa24b ref s/heads/master 
Cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1 .0 
95851 91 f 37f 7b0f b9444f 35a9bf 50de1 91 beadc2 ref s/tags/v1 . 1 
A 1 a41 0efbd13591 db07496601 ebc7a059dd55cfe9 



이 상 태에서 레퍼 런스를 수 정하면 파일을 수 정하는 게 아니라 refs/heads 폴더에 파일을 새로 만 든다. 
Git 은 레퍼 런스가 가 리키는 SHA 값을 찾을 때 먼저 refs 디텍토 리에서 찾고 없으면 packed-refs 파일에 
서 찾 는다. 그 러니까 어떤 레퍼 런스가 있는데 refs 디텍토 리에서 못 찾으면 packed-refs 에 있을 것 이다. 

마 지막에 있는 8 로 시 작하는 줄을 살펴 보자. 이것은 바로 윗줄의 태그가 Annotated 태 그라는 것을 말 
해 준다. 해당 커밋은 윗 태그가 가 리키는 커밋 이라는 뜻 이다. 



9.7.2 데이 터복구 

Git 을 사 용하다 보면 커밋을 잃어 버리는 실수를 할 때도 있다. 보통 작업 중인 브 탠치를 강제로 삭제하 
거나, 어떤 커밋을 브탠치 밖으로 고집어 내버렀 거나, 강제로 (Hard) Reset 하면 그렇게 될 수 있다. 어 
쨌든 원치 않게 커밋을 잃어 버리면 어떻게 다시 찾아야 할까? 

master 브 랜치를 예견 커 밋으로 Reset 하고 그것을 다시 복구해 보자. 먼겨 연습용 저 장소를 만 든다: 



$ git log — pretty=oneline 

ab1 af ef 80f ac8e34258f f 41 f d b867c702daa24b modified repo a bit 
484a59275031 909e1 9aadb7c9226271 9cf cdf 1 9a added repo.rb 
1 a41 0ef bd1 3591 db07496601 ebc7a059dd55cf e9 third commit 
Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
f df 4f c3344e67ab068f 836878b6c4951 e3b1 5f 3d first commit 



master 브탠치 를예견 커 밋으로 Reset 한다: 
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$ git reset —hard 1 a41 0ef bd1 3591 db07496601 ebc7a059dd55cf e9 
HEAD is now at 1a410ef third commit 
$ git log — pretty=oneline 



1 a41 Oef bd1 3591 db07496601 ebc7a059dd55cf e9 third commit 
Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 
f df 4f c3344e67ab068f 836878b6c4951 e3b1 5f 3d first commit 




최근커 밋두개 는어떤 브랜치 도가리 키지않 는다. 잃어 버렀다 고볼수 있다. 그두커 밋을브 탠치에 
다시 포함 하려면 마지막 커밋을 다시 찾아야 한다. SHA 값을 외웠을 리도 없고 뭔가 찾아낼 방법이 필 
요 하다. 

보통 git ref log 명 령을사 용하는 게가장 쉽다. HEAD 가 가리키 는커밋 이바뀔 때마다 Git 은 자동으 
로 그 커밋이 무 엇인지 기록 한다. 새로 커밋 하거나 브 탠치를 바꾸면 Reflog 도 늘어 난다. "Git 레퍼런 
스" 결에서 배운 git update— ref 명렁 으로도 Reflog 를 남길 수 있다. 이 것이 git update— ref 를 꼭사용 
해야 하는이 유중에 하 나다. git reflog 명령만 실 행하면 언제나 발 자취를 돌아볼 수 있다: 



$ git reflog 






1a410ef HEAD@{0}: 


1 a41 Oefbdl 3591 db07496601 ebc7a059dd55cfe9 ： 


updating HEAD 


ablafef HEAD@{1}: 


ab1 afef80fac8e34258ff41 fc 1 b867c702daa24b ： 


updating HEAD 



Checkout 했 었던커 밋두개 만보여 준다. 구체 격인정 보까지 보여 주진않 는다. 좀더 자세히 보려면 

git log -g 명 렁을사 용해야 한다. 이 명렁은 Reflog 를 log 명렁 형식으 로보여 준다. 



$ git log -g 

commit 1 a41 0efbd1 3591 db07496601 ebc7a059dd55cfe9 

Reflog: HEAD@{0} (Scott Chacon <schacon@gmail.com>) 

Reflog message: updating HEAD 

Author: Scott Chacon <schacon@gmail . corn) 

Date: Fri May 22 18:22:37 2009 -0700 

third commit 

commit ab1 afef80fac8e34258ff41 fdb867c702daa24b 

Reflog: HEAD@{1 } (Scott Chacon <schacon@gmail.com>) 

Reflog message: updating HEAD 

Author: Scott Chacon 〈schacon@gmail.com〉 

Date: Fri May 22 18:15:24 2009 -0700 

modified repo a bit 

두번째 커 밋을잃 어버린 것이니 까그커 밋을가 리키는 브탠치 를만들 어복구 한다. 그커밋 (ablafef) 

을 가 리키는 브탠치 recover— branch 를 만 든다: 
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$ git branch recover— branch ablafef 

$ git log — pretty=oneline recover-branch 

ab1 af ef 80f ac8e34258f f 41 f d b867c702daa24b modified repo a bit 

484a59275031 909e1 9aadb7c9226271 9cf cdf 1 9a added repo.rb 

1 a41 Oef bd1 3591 db074966O1 ebc7a059dd55cf e9 third commit 

Cac0cab538b970a37ea1e769cbbde608743bc96d second commit 

f df 4f c3344e67ab068f 836878b6c4951 e3b1 5f 3d first commit 



master 브 탠치가 가 리키던 커밋을 recover-branch 브 탠치가 가 리키게 했다. 이 커밋두 개는 다시 도달 
할수 있다. 

이보다 안 좋은 상황을 가정해 보자. 잃어 버린 두 커밋을 Reflog 에서 못 찾 았다. recover-branch 를 다 
시 삭 제하고 Reflog 를 삭 제하여 이 상황을 계연 하자. 그러 면그두 커밋은 다시 도달할 수 없게 된다: 

$ git branch -D recover-branch 
$ rm -Rf .git/logs/ 

Reflog 데 이터는 .git/logs/ 디랙 토리에 있기 때문에 그 디텍 토리를 지우면 Reflog 도 다지워 진다. 
그러면 커밋을 어떻게 복구 할수있 을까? 한 가지 방법이 있는데 git fsck 명 렁으로 데 이터베 이스의 
Integrity 를 검사할 수 있다. 이 명렁에 -full 옵션을 주고 실 행하면 길 잃은 개체를 모두 보여 준다: 

$ git fsck —full 

dangling blob d670460b4b4aece591 5caf 5c68d1 2f 560a9f e3e4 
dangling commit ab1afef8Ofac8e34258ff41fc1b867c702daa24b 
dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9 
dangling blob 71 08f 7ecb345ee9d00841 93f 1 47cdad4d2998293 

이 Dangling 커 밋이잃 어버린 커밋이 니까그 SHA 를가리 키는브 탠치를 만들어 복구 한다. 
9.7.3 개 체삭제 

Git 은 장점이 매우 많다. 하 지만, Clone 할 때 히스 토리를 견부 내 려받는 것이 문제가 될 때가 있을 수 
있다. Git 은 모든 파일의 모든 버견을 내려받 는다. 사실 파일이 모두 소스코 드라면 아무 문제 없다. Git 
은 최 격화를 잘해서 데 이터를 잘 압축 한다. 하 지만， 누군가 매우 큰 파일을 넣어 버리면 Clone 할 때마 
다 그 파일을 내려받 는다. 다음 커 밋에서 그 파일을 삭 제해도 히스토 리에는 그대로 남아 있기 때문에 
Clone 할때마 다포함 된다. 

Subversion 이나 Perforce 겨 장소를 Git 으로 변환할 때에도 문제가 된다. Subversion 이나 Perforce 
시 스템은 전체 히스 토리를 내 려받는 것이 아 니므로 해당 파일이 여러 번 추가될 수 있다. 아니면 다른 
VCS 에서 Git 저 장소로 임포트 하려고 하는데 Git 저 장소의 공간이 충 분하지 않으면 너무 큰 개체는 찾 
아서삭 제해야 한다. 

주의: 이 작업을 하다가 커밋 히스 토리를 망 처버릴 수 있다. 삭제 하거나 수정할 파일이 들어 있는 커밋 
이후에 추가된 커밋은 모두 재작성 된다. 프로 젝트를 임포트 하차 마차 하는 것은 괜 찮다. 아직 아무도 새 
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겨 장소를 가지고 일하지 않기 때문 이다. 그게 아니면 히스 토리를 Rebase 한다고 관련된 사람 모 두에게 
알려야 한다. 

시 나리오 하나 살펴 보자. 먼저 저 장소에 크기가 큰 파일을 넣고 다음 커밋 에서는 삭제할 것 이다. 그리 
고 나서 그 파일을 다시 찾아 저장 소에서 삭제 한다. 먼저 히스 토리에 크기가 큰 개체를 추가 한다: 

$ curl http ： //kernel . org/pub/ software/ scm/git/git-1 .6.3.1. tar . bz2 > git .tbz2 

$ git add git.tbz2 

$ git commit —am 1 added git tarball 1 

[master 6df7640] added git tarball 

1 files changed, 0 insertions(+) , 0 deletions(-) 

create mode 1 00644 git.tbz2 



tar 파일을 넣고 다 시삭제 한다: 

$ git rm git. tbz2 
rm 'git . tbz2' 

$ git commit -m 'oops - removed large tarball 1 
[master da3f30d] oops - removed large tarball 

1 files changed, 0 insertions(+) f 0 deletions (- 

delete mode 100644 git.tbz2 



gc 명 렁으로 최격 화하고 나서 저장소 크기가 얼마나 되는지 확인 한다: 

$ git gc 

Counting objects: 21 , done. 
Delta compression using 2 threads. 
Compressing objects: 100% (16/16) x done. 
Writing objects: 100% (21/21), done. 
Total 21 (delta 3), reused 15 (delta 1) 



count-objects 명 렁은사 용하는 용량이 얼마나 되는지 알려 준다: 

$ git count-objects -v 
count: 4 
size: 16 
in-pack: 21 
packs: 1 
size-pack: 2016 
prune— packable: 0 
garbage: 0 
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size-pack 항목의 숫자가 Packfile 의 크 기다. 단위가 길 로바이 트라서 이 Packfile 의 크기는 약 2MB 이 
다. 큰 파일을 커 밋하기 견에는 약 2K 였다. 파일을 지우고 커 밋해도 히스토 리에서 삭 제되지 않 는다. 어 
쨌든 큰 파일이 하나 들어 있기 때문에 너무 작은 프 로젝트 인데도 Clone 하는 사 람마다 2MB 씩 필요하 
다. 이제그 파일을 삭제해 보자. 

먼겨 파일을 찾 는다. 뭐, 지금은 무슨 파 일인지 이미 알고 있지만 모 른다고 가정 한다. 어떤 파일이 용 
량이 큰지 어떻게 찾아 널까? 게다가 git gc 를실행 됐으면 전부 Packfile 안에 있어서 더 찾기 어 렵다. 
Plumbing 명렁어 git verify-pack 로 파일과 그 크기 정보를 수 집하고 세 번째 필드를 기 준으로 그 결 

과 를정럴 한다. 세 번째 필드 가파일 크 기다. 가장 큰파일 S 개만 삭제할 것이기 때문에 tail 명 령으로 
가장 큰파일 3 개 만골라 낸다. 



$ git verify-pack -v .git/objects/pack/pack-3f8c0. . .bb. idx ！ sort _k 3 — n 


I tail -3 


e3f094f522629ae358806b17daf78246c27c007b 


blob 


1486 734 4667 




05408d1 95263d853f09dca71d551 1 6663690c27c 


blob 


12908 3478 1189 




7a9eb2fba2b1 81 1 321 254ac360970fc169ba2330 


blob 


2056716 2056872 5401 





마 지막에 있는 개체가 2MB 로가장 크다. 이제그 파일이 정확히 무슨파 일인지 알 아내야 한다. 7 장에 
서 소 개했던 rev-list 명령에 —-objects 옵션을 추 가하면 커밋의 SHA 값과 Blob 개체의 파일 이름, SHA 
값을 보여 준다. 그 결 과에서 해당 Blob 의 이름을 찾 는다: 

$ git rev-list ―— objects ―— all ！ grep 7a9eb2fb 
7a9eb2fba2b1 81 1 321 254ac360970fc169ba2330 git . tbz2 

히스 토리에 있는 모든 Tree 개 체에서 이 파일을 삭제 한다. 먼겨 이 파일을 추가한 커밋을 찾 는다: 

$ git log — pretty=oneline —branches ― git . tbz2 

da3f 30d01 9005479c99eb4c340622561 3985a1 db oops - removed large tarball 

6df764092f3e7c8f5f94cbe08ee5cf42e92a0289 added git tarball 



이 파일을 히스토 리에서 완견히 삭 제하면 6df76 이후 커밋 은모두 재작성 된다. 6 장에서 배운 filter- 
branch 명렁으 로삭제 한다: 

$ git filter-branch ―— index-filter \ 

'git rm ―— cached ―— ignore— unmatch git.tbz2' ―— 6df7640 A . . 
Rewrite 6df764092f3e7c8f5f94cbe08ee5cf42e92a0289 (1/2)rm 'git.tbz2' 
Rewrite da3f 30d01 9005479c99eb4c340622561 3985a1 db (2/2) 
Ref 'refs/heads/master' was rewritten 



-index-filter 옵션은 6 장에서 배운 —tree-filter 와 U ᅵ숫 하다. —tree— filter 는 디 스크에 Checkout 

해서 파일을 수정 하지만 —index— filter 는 Staging Area 에서 수정 한다. 삭제도 o! file 명렁이 아니 

라 git rm -cached 명렁으 로삭제 한다. 디스 크에서 삭제하 는것이 아니라 Index 에 서삭제 하는것 이다. 



254 



Scott Chacon Pro Git 



9.8 절 요약 



이렇 게하는 이유는 속도 7 \ 빠르 7 1 때문 o | 다. Fi Iter 를 실행할 때 마 다각리 비견을 디 스크에 Checkout 

하지 않기 때문에 이것이 울트라 캡승 더 빠 르다. -tree-filter 로도 같은 것을 할 수 있다. 단지 느릴 뿐 
이다. 그리고 git rm 명령에 -ignore—unmatch 옵션 을주면 파일이 없는 경우에 에 러를출 력하지 않는 
다. 마지 막으로 문제가 생긴 것은 6df7640 커밋부 터라서 filter-branch 명렁에 6df7640 커 밋부터 재작성 
하라고 알 려줘야 한다. 그렇지 않으면 첫 커 밋부터 시 작해서 불 필요한 것까지 재 작성해 버 린다. 

히스 토리에 서는더 는그파 일을가 리키지 않 는다. 하 지만, Reflog 나 filter-branch 를 실행할 때생기 

는 레퍼 런스가 남아 있다. filter— branch 는 .git/ref s/original 디텍 토리에 실행될 때의 상태를 저장한 
다. 그래서 이 파일도 삭 제하고 데 이터베 이스를 다시 압 축해야 한다. 압 축하기 전에 해당 개체를 가리 
키는레 퍼런스 는모두 없애야 한다: 



$ rm -Rf .git/refs/original 
$ rm — Rf .git/logs/ 
I git gc 

Counting objects: ^9, done. 
Delta compression using 2 threads. 
Compressing objects: 100% (14/14), done. 
Writing objects: 100% (19/19), done. 
Total 19 (delta 3), reused 16 (delta 1) 




공간이 얼마 나결약 됐는지 확인 한다: 



$ git count-objects -v 
count: 8 
size: 2040 
in-pack: 19 
packs: 1 
size-pack: 7 
prune-packable: 0 
garbage: 0 

압축된 저 장소의 크기는 가 〈로 내려 갔다. 2MB 보다 한참 작다. 하 지만, size 항목은 아직 압 축되지 않 
는 Loose 개체의 크기를 나타 내는데 그 항목이 아직 크다. 즉, 아직 완전히 제거된 것은 아 니다. 하 지만, 
이 개체는 Push 할 수도 Clone 할 수도 없다. 이 점이 중요 하다. 정말로 완견히 삭제 하려면 git prune 
-expire 명 령으로 삭 제해야 한다. 



9.8 요약 

Git 이 내부 적으로 어떻게 동작 하는지 뿐만 아니라 어떻게 구 현됐는 지까지 잘 알게 됐을 것 이다. 이 장 
에 서는저 수준명 렁어인 Plumbing 명렁어 를설명 했다. 다른 캉에서 우리가 배웠던 Porcelain 명렁어 
보다는 단순 하다. Git 이 내부 격으로 어떻게 동작 하는지 알면 Git 이 왜 그렇게 하 는가를 더 쉽게 이해할 
수 있을 뿐만 아니라 개인 격으로 필요한 도구나 스크 립트를 만들어 자신의 Workflow 를 개선할 수 있 
다. 
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Git 은 Content-addressable 파일 시스 템이기 때문에 VCS 이상의 일을 할 수 있는 매우 강력한 도구 
다. 필차는 독차가 습둑한 Git 내부 지식을 활 용해서 필요한 애 플리케 이션을 직집 만들면 좋 겠다. 그리 
고 진정 Git 을 꼼 꼼하고 디테 일하게 다룰 수 있게 되길 바 란다. 
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